たてよこWebアワードに応募をした

こんにちは！あけましておめでとうございます(◜௰◝)2017年初の投稿です。

2017年がすでに2ヶ月終わってしまいましたが、いかがお過ごしでしょうか？！私はいちご大福をもちもち食べています(3日で5個)。

さて久しぶりのブログとなりますが、今年に入ってからの私はと言うと、「たてよこWebアワード」へ応募をするための作品作りをして過ごしておりました＾＾

cssのvertical-modeを利用したWebでの縦書き表現の可能性を探る(?)素敵なアワードです。

こんなにおしゃれでイケてるサイトに応募をするのはとっても勇気がいったのですが、去年同アワードに出したくても出せなかった雪辱を晴らすべく恥を忍んで応募をすることを決意しました…！

制作をしたサイトがこちらになります。

「読める辞典」という作品です(◜௰◝)

簡単に経緯等を。

• デザイン
• コーディング

デザイン

デザインのアイディア自体は、大学3年時に学校の課題で制作をした体験する辞典、というもののリメイクをしたものです。

「縦書き」と「辞典」というワードがマッチしているなと感じたというのと、「体験型」というところが、Webサイトとユーザーとの間で行われるコミュニケーションを利用してインタラクティブにうまく表現できるのでは？と考えたため今回の題材として取り上げることにしました！

そして今年に入って、4年添い遂げたMacBookAirに別れを告げ、新型MacBookProを手に入れたことで作業環境をパワーアップをしました！

さらに、ついにMORISAWA PASSPORTを契約しまして、美しいフォントが使い放題という環境を作りました＾＾

去年購入した液タブ(CINTIQ13)も揃っているので、イラスト素材も作り放題です！これで作業環境は整った＾＾＾

ここからデザインを初めたので、実際に手を動かし始めたのは1月の半ばあたりでした。なかなかのヒヤヒヤスケジュールです。

デザイン作成ツールはいつもと同じくAdobe PhotoShopです。

コーディング

コーディングは前回のNo.11様サイト制作時と同様に、Gulpを使用してcssはSassでコーディングを行いました。

今回新たにチャレンジした点は主に以下です！

• css3アニメーションでゴリゴリアニメーションするものを作る！
• フレキシブルなデザインを作る！
• Webフォントを使う！
• 上記cssアニメーションとWebフォントを使用しても、パフォーマンスが悪くないものを作る！

css3アニメーション

サイト内で動いている箇所は、全てcss3のanimationで実装をしています！

こことか

こことか

animationを素で書くとどうしても冗長で見にくいコードになってしまいがちで、どう管理していけばよいのかが課題でした…

今回は以下のような方法でやってみています。

例えば、ここのばらばらの文字がふわふわと動くところの場合。

まずはanimationの各ブラウザのベンダープレフィックス入りのmixinを作ります。

こんな感じ。引数でkeyframesの名前を指定できるようにしておきます。

次に実際に指定したいkeyframesを作ります。

「bobbingMotion」という名前のkeyframesで、時間内(animation-duration)の50%の時に指定した要素の20%分下がる、というものです。

あとはこの動きをつけたい要素のcssに、最初に作ったanimationのmixinにkeyframes名の「bobbingMotion」の引数を入れて上げたものをmixinで読み込ませればOKです！

こんな感じで書いてあげると、6秒間かけて1回文字が下に落ちてもとに戻る、という動きを永遠に繰り返す(infinite)ということができます＾＾

こういった形で、各アニメーションを設定していきました！

複雑なアニメーションも、細かいアニメーションの組み合わせでできるようにしたいな〜と思っていたのですが、

そもそもanimationを1つの要素に2つ以上は指定できないし、独自の動きをするものはそれぞれのkeyframesを作った形になりました…( ˘ω˘)

ゴリゴリのアニメーションは結局は泥臭くなりがちなのかしら、もっと良い方法をご存じの方がいらしたらぜひ教えてほしいです…！！

フレキシブルなデザイン

今回はレスポンシブデザインでPC・タブレット・スマートフォンに対応をさせています。

各デヴァイス様々な画面サイズで見た時に、できるだけデザインの印象が変わらないようにしたいと思い、フレキシブルにデザインを見せる方法を模索しました。

そこでフォントサイズや要素の単位に、「vw」、「vh」をところどころ採用することにしました！

この作品は未来のための挑戦ということで、対応環境は各ブラウザ・OS最新版のみとしております＾＾vw、vhは対応していないブラウザ・OSがあるので実践で使う場合は注意が必要です。

下記で詳しい解説がされていますのでぜひ！

• 【css3】最新の単位[vw] [vh] [vmin] [vmax]の解説

使ってみた感想としては、当たり前ですが使い所をしっかり見極めるべし、というところでした＾＾；

例えば、サイトのメインビジュアル内ロゴのフォントサイズはvhで指定をしています。

通常のPCのように、横幅が縦幅より短い画面の規格であれば、どんなサイズでも割りといい感じにフィットしてくれます！

…しかし失念していたのが、横幅が縦幅より短い場合のPC…！一般の方であれば、そんな風に使われる方は少ないのかなとは思われるのですが、

我々のようなWeb制作に携わっている方の場合、ディスプレイを2枚並べ、うち片側を画面縦置きで使用することも少なくない…！ということに気がついてしまったのです＾＾q＾会社の自PCで見て慌てふためきました。

今回は応急処置として、mediaQueryのタブレットデザイン用画面幅を、768px〜1200pxとして(私のPCが1200*1920pxだったため)、横幅1200pxの画面ではタブレットのデザインを見せるようにしました、、パワープレイというやつです。

ということで、あらゆる画面幅や規格を加味してvw/vhは使用する必要があるなと痛感しました＾＾

でも使いこなしたら絶対便利なので、今後とも積極的に取り入れられるところには使っていこうと思います！

Webフォント

前述したように、今年からMORISAWA PASSPORTを契約しまして、それにより「TypeSquare」でモリサワフォントのWebフォントが使い放題になりました！

夢のごとし。それに加えてモリサワフォントにないフォントはAdobe「Typekit」も使用しました。

で、後になって気がついたのですが、実は私リリース直前くらいまでMORISAWA PASSPORTを契約していると、TypeSquareが無料で使い放題であるということを知らず、TypeSquareと別途契約をして、1フォントのみ1万PV / 月までであれば無料で使用できるプランを使っていたのでした…

なので、TypeSquareとは別で、Typektで和文フォントをもりもり使っているのですが、先にこの事実を知っていれば、和文フォントはTypeSquareで揃えて、足りない欧文をTypekitで調達、という方法のほうが良かったかもしれません(後述しますが、パフォーマンス面で問題が出ました)。

因みにMORISA PASSPORT契約でTypeSquareが使い放題の件は、こちらに方法が記載されています。（個人的にめちゃめちゃわかりにくいなと思いました＾＾＾）

ということで、TypeSquareでは「A1明朝」という美しい明朝体を使用し、

Typekitでは以下のフォントを使用しました！

• Futura
• Garamond
• 平成角ゴシック
• TB新聞ゴシック
• TB新聞明朝

こちらにTypekitで使用しているフォントをまとめています。

これらを利用してWebフォントの導入をしました！

パフォーマンス問題

コーディングをして直面したのがパフォーマンス問題…！

これまでそこまでゴリゴリのアニメーションサイトを作る機会がなかったので、私にもついにこのことを考えるときが来てしまったか…と、最後の最後で高いぬりかべに立ちはだかられる状況に。

まずパフォーマンスに影響しているのでは？と睨んだのがcssのアニメーション方法でした。

例えば、メインビジュアルすぐ下にある、文字が上から下へ斜めに落ちていくアニメーションと、右から左へ流れていくアニメーション、ここがSafariで表示した時に、カックカクに動いてしまってスルスルときれいに流れない、という状態でした…

そこで、会社のエンジニアさんにお伺いをたてたところ、

「position」で位置移動をさせるよりも「transform」でやった方が描画の「リペイント」が都度起こらないため、パフォーマンスよくできるよ！ということお告げが！ありがたすぎて泣けます。

早速transformに変更していくZ！！…とその前に、「リペイント」ってなんぞ＾＾＾q＾？ということで、そこからスタート。

教えていただいた下記の記事などを読みました！

• ハイパフォーマンス・アニメーション
• ブラウザ動作の理解ーリフローとリペイント及びその最適化ー
• Webサイトのパフォーマンス改善を行うためにGPU処理を取り入れてみた
• [フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう

ここから、そもそもDOMとは？？となり、諸々調べてみました。（ここでは省略します！）

DOMとCSS Object Model (CSSMO)が合わさって、レンダーツリーが作られて、それをリフロー(レイアウト)してからペインティングが行われてブラウザ上に表示される、ということと理解しました。

positionで指定をすると、positionはリフローに影響を与えるプロパティのため、アニメーションのたびにリフロー⇛ペインティングの工程を経ないといけなくなるため(リペイント)、パフォーマンスが悪くなる、ということのようでした。なるほど！

その点、transformはリフローに影響を与えず、都度ペインティングをする必要なくアニメーションをさせられるためパフォーマンスがよいらしいです。

このあたりはまだしっかり理解を深められていないところなので、言い回しなどおかしいかもしれないのですが、ざっくりとpositionよりtransformのほうがパフォーマンスいいよ！ということだけ…！

というところで、positionでアニメーションさせていた箇所を、可能な限りtransformに変更！

Chromeのデベロッパーツールで見てみると、以前よりリペイントされている箇所がかなり減ってスッキリしました＾＾＾

そして、動きを確認してみた結果、Safariでのアニメーションのカクつきが滑らかに\\٩( ‘ω’ )و //ヤッター！

がしかしもう一つ問題が。。

スマートフォンでの表示が泣きたいくらい遅い…(´；ω；｀)

animationのパフォーマンスもかなり上がったと思われるし、まったく理由がわからず……時が流れること3日。

そんなところに、「Website speed test」というWebサイトのパフォーマンスなどを解析してくれるサービスを知りました！

使い方は簡単で、「URL」の部分にスピードを計測したいサイトのURLを入力し、そのサイトを見ている場所、と仮定する場所をセレクトボックスから選びます。私は適当にNewYorkとかにしたような覚えがあります。NYかっこいいですから。

で、ウーロン茶でも飲みながら結果を待ちます…(◜௰◝)

そして……

でたーーーっ！！

※こちらは現状のサイトの状態のものです。

あんなことやこんなことが見えちゃいます＾＾

そこで、驚いたのが「Content size by domain」部分。

ここの一番上に来ていた、一番大きなサイズのものが「use.typekit.net」で、なんと当初3MBくらい(?)になっていたのです…！

原因cssじゃなかったーー＾＾＾！！（でも結果cssのパフォーマンス改善ができたので良しです）

ということで、Typekitの中身をちょっと整理して、UA判定でPC・タブレット版の場合はTypekitを読み込ませて、

スマートフォンの場合は読み込ませないようにし、スマートフォンのデフォルトのフォントでも、ひどいデザインにならないようにcssでサイズやウェイトの調整をしました。

UA判定には「isMobile」を使用させていただいてきました＾＾

そんなこんなで書いていたら長くなってしまいましたが、約1ヶ月半で制作をしました！

わーっと書きましたが、Webでの縦書き表現による自由なレイアウトの広がり、新しいインターフェース、美しい日本語の見せ方の可能性の広がりを感じられる、本当に素敵なアワードでした！何より楽しかったです(◜௰◝)

運営をされている会社様、協賛の企業様に感謝です。

日本語Webの未来が楽しみですね！と大きなことを言ってみます\\٩( ‘ω’ )و //

それでは素敵な春をお過ごしください＾＾以上！

• 
• 
•