nantekkotai's blog

おもに技術とお仕事に関連することを書いています。

CSSとJavaScriptにおけるアニメーションの分担

velocity.jsというものがありまして、アニメーションの制御においてはいままでのjQueryのanimateはもとよりCSSアニメーションと比べてもパフォーマンスが良いとのことです。
http://julian.com/research/velocity/

という話の枕があったとして。
それでも役割は分担できるなと思いましたのでそのメモ。

CSSアニメーションに適していること。

それは、

  • DOM制御を伴わない
  • 装飾的なアニメーション

というもの。
たとえば以下のページのアニメーションは全てCSSで制御されています。
http://tympanus.net/Development/HoverEffectIdeas/

こういうスタイリング的なアニメーションはCSSの方が管理しやすいです。
JavaScriptだとタイミングよって想定していない動作を引き起こす可能性があります。
たとえばアニメーション途中でイベントの向きが切り替わるマウスアクションを行ったりすると、いきなり始点に戻って再度アニメーションを始めるとかありえそうですね。

CSSアニメーションなら途中でイベントの向きが変えても、元に戻るアニメーションが実行されるだけです。
イベント系の管理、想定外の動作に対応するためのコードというものが不要になるので楽なんですね。

JavaScriptで管理すべきアニメーションとは

たとえば通知バーの出し入れとかですね。
もちろん、DOMの表示/非表示だけをJSでやり、アニメーションはCSSで、という分担もありですが、大抵こういう仕組みはアニメーションの終わりをきちんと把握してからDOMを削除したいものなので、全部JSで制御した方がいいと思います。

JavaScriptアニメーションの何が良いのかというと、他のイベントとの連動や関数への伝播などでしょう。
たとえば画面インタラクションから、サーバとの非同期通信を前提としたリストの追加や削除というものに関しては、アニメーション面においてもJavaScriptで制御するのが良いかと思います。

まとめ

JavaScriptCSSで必ず分けなきゃいけないということではないです。
ただ、どちらも役割の違うアニメーションを実装することになるので、無理にどちらかにまとめるよりかは分割した方が、メンテナンス性の高いコードになるかと。

「知ってる」と「できる」の差を図にしてみる

こんな感じじゃないかと思います。

f:id:nantekkotai:20140416220442p:plain

まだできないけど知ってるという状態では「ゴールは目前」と思い込んでしまうから危ない。
本とか読んで「あーはいはい楽勝ですね」などと思っていざ実装しようとすると、肝心のところ以外の場所で嵌まりまくりでなかなか進捗しないとかね。よくあります。

ページ遷移のインタラクションはブラウザに任せっぱなしにせず、もっと画面側で制御した方が良いのではないかと云う話

pocketのログインで気付いたことを書きます。

pocketというのは「あとで読む」系の人気サービスです。
最近日本語化されました。
僕は、はてブなんか使わないで、こっちをメインに利用しています。

pocket
https://getpocket.com/

日本語化される少し前に、ログインフォームが変わりました。
今ログインしようとすると幅の狭いフォームが表示されます。

f:id:nantekkotai:20140403225847p:plain

ログインフォームの入力項目はAjaxでPOSTされて、そこでエラーならメッセージが返ってくるし、成功だったらそのまま自分のpocketのトップページに遷移します。
それでAjax送信中に当然のごとくloadingの表示があるわけですが、ログインに成功すると以下画像のようにloading状態のまま遷移するわけです。

f:id:nantekkotai:20140403225914p:plain

僕はこれを「いいな」と思いました。
ただログイン情報をPOSTして、成功したら別画面に遷移するだけなんですけど。
このWebページが切り替わるフローに、あまりストレスを感じないということが「いいな」と。

大抵のWebサービスやサイトでは、遷移中の反応をブラウザに任せているわけですよ。
Chromeのタブの中でクルクル回るローダーをよく見ますよね。あるいはURLバーでクルクル回るやつ。

ブラウザのリンクを押して別画面に遷移するアクションでも、リンクの近くでローディングなんてさせないじゃないですか。
ブラウザの機能としてクルクル回るのあるから別にいいやって今まで思ってたわけです。

でもpocketの「submitしてから遅延無くローディングが始まって、成功したらそのまま遷移する」のを見て、おやっと思いました。
この一連の流れであらためて気付かされたことは「ブラウザの緩慢な遷移に対しては単に慣れていただけ」「本当は見えないストレスを感じていたのではないか」ということです。

Webの遷移をストレスと感じる傾向は、スマホアプリを利用するようになって顕著に感じられるようになりました。アプリのあのスムーズな遷移を体感してしまうと、スマホでWebアプリとか使う気にならないんですね。

Webブラウザでは、

  • 通信して
  • HTMLとCSSを取得して
  • layoutして
  • paintして

という処理にどれだけ速くても数百ミリ秒はかかってると思います。
サーバが重くなってたり、通信状況が悪かったりすればもっとかかります。
Webのフロントエンドを担当する僕らみたいな人間は、こういう処理と処理の隙間の時間に対してもっと敏感なって、インタラクションを設計したら良いんじゃないかと思いました。

pocketのログインはAjaxだからこそこういう動作を取り入れたのだと思いますけど、通常の遷移するリンクやボタンにもローディングやプログレスを画面上に出す工夫があって良いかと。
片っ端から適応するとアレなので、ログインとか投稿とかユーザーによる明示的なアクションに対しては、インタラクションをブラウザに任せっぱなしにせず、ちゃんと画面上で反応を返す設計を行うべきかもしれません。

マイクロインタラクション ―UI/UXデザインの神が宿る細部

マイクロインタラクション ―UI/UXデザインの神が宿る細部

大事なことは、できるだけラクをすること。

仕事で受け入れテスト的なものを用意しようということに、個人的になりまして、今日は一日CasperJSについてあれこれ触ってました。

候補としては他にもcapybara-webkitとかnightwatchとか調べたんですけど、なんかめんどくさそうだし、なんというかサクッと理解できなかった。というかCasperJSの使い方がすんなり頭に入ったので「これだな」という感じで決めました。

実際使ってみて「イケそうだ!」という感覚を得られたわけで、明日から(というか明日中に)ガリガリと必要な分の受け入れテストを書くつもりなんですけど、この「なんとなくイケそうなので選んでみたら、やっぱりイケました」という感じは以前にもあって、それはKnockoutJSを採用したときもそうだったなと思い出したわけです。

KnockoutJSの選択

クライアント側のフレームワーク使って作りたいな、という案件でした。
2年くらい前で、当時は「JS?フレームワーク?だったらBackboneだろう」という感じでしたけど。
でも僕は、双方向データバインディングでMVVMなKnockoutの方を選択したわけです。

いろいろ理由をこじつけて選択したわけですけど、一番の理由はすんなり理解できたから。そんでラクそうだった。
実際ラクでした。それはもう、jQuery的なラクさ。

選択の基準はラクさ

大事なことは、CasperJSにしろKnockoutJSにしろ、自分にとってのラクさで選んだと言うことです。
もっとスキルのある人たちなら、違う選択をしたかもしれない。長い目で見て、別の選択肢(BacknoneやAngularJSとか)を選んだかもしれない。
自分がプログラマとしては平凡なのと、コードよりもプロダクトの方に関心があるということもあって、目的を達成させる工程に関しては自分が理解しやすいものを選ぶ、そう考えたわけです。

で、何が言いたいのかというと、

本当に解決したい課題以外のことは、できるだけラクな道を選んで良い。

ということです。

集中するためにラクをする

自分にとって「それこそが解決したい課題である」と呼びたいものに集中する。 ここに関わるもの以外はすべて、ラクしていい。
ズルと言ってもいい。
それくらい割り切って、選択して良いのではないか。

自分にとって大事な課題に集中できるのであれば、へぼプログラマと呼ばれようがクソエンジニアと思われようが何だって構わないのです。

自分が見つけた課題。
それを解決するときに生まれる価値。
そこから生み出されるチームへの貢献。

それぞれの人が、それぞれの課題に集中できるようになること。
それが理想かなと思いました。

マネジメントをやるタイミング

ここ一年ディレクションとエンジニアを両方兼務していて、大変だったのだけどいろいろ気付くことも多く、自分なりにキャリアについて深く考えるきっかけにもなりました。

この1年で自分が強く感じたことは、統合的役割であるマネージャーやディレクターになる選択をするのは、自らにとって深く理解したいと願う何かしらの分野について専門家とみられるくらいの能力を持つようになってからの方が良いのではないのか、ということです。

なんでこんなことを考えるかというと、誰かに指示を出したり、決断する、判断するという行為には寄って立つところの価値観や視点というものが欠かせないと強く感じたから。
もし中途半端な能力の状態でディレクターやマネージャーになってしまったら、悲劇なのかもしれない。抜擢であると考えることもできるけれど、地力があったから抜擢されたのか、たまたま調子が良いところを「地力」があると判断(誤解)されて、抜擢されて「しまった」のか、この違いをちゃんと把握しないといけない。

組織的にすぐ元の場所に戻れるのならそれで良いけれど、「自分はエンジニアに向いてなかったからディレクターなろう」などと、ある種の逃げの手として「でもしか」的選択で統合的役割の仕事を選択するとキャリア形成に失敗するのでは、という危惧があります。

この本の中で「自律をしないで統合の役割を担う悲劇」というパートがあります。
自律とは「自分で試行錯誤を繰り返して、自分なりの仕事のやり方や意識を確立すること」と、この本では書いてあります。自律を経なければ一流への扉は開かれません。自分で考え、いろいろ試して、それで初めて組織内外から認められる一流へと進化するそうです。ポケモンみたい。

ところが、日本の組織というのはなぜか自律の段階をすっ飛ばして「統合的役割」の仕事、いわゆる管理職に「ステップアップ」しちゃうことが多いのです。
悲しいことに、自律段階を得ないで管理職になるとそこはキャリアの行き止まりで先に進めない、という世界観がこの本では展開されています。間違った技術ツリーを組むとライバル国に大きく遅れをとって滅亡の危機に瀕してしまう某シヴィライゼーションというゲームみたいなことが起きる訳ですね。

まあここまではこの本の話ですが、自分が考えていたのは、自律を経ないで判断する立場になると、決定の軸はぶれるし、そのための判断もおかしいことになるし、ぶっちゃけ自分が正しいのかどうかの自信も無く、間違ったことをたくさん犯すくせに学習しない、みたいな厄介な人になるのではないかと踏んでいます。

自律の段階で一番重要なのは「自分で考えて試行錯誤して正解に辿り着く」ということだと思います。これを十分にこなしていない人は、上下関係を別として、質の高い決定というものが行えないのではないかと思うのです。

決定を下すための様々な判断というのは、妄想ではなくて現実に対応する形で行われますが、この「現実に対応する」ということこそ「試行錯誤」によって経験する重要なファクターじゃないかなと。

何でもいいので、自分の専門分野について自律的に活動し、出来れば一流を目指してからマネジメントやディレクションに入るのが良いのではないかなと思いました。

ビジネスモデルより先にあるべきこと

先月たまたま購入したハーバードビジネスレビューが面白かったので、今月も購入してみました。題材は「ビジネスモデル」について。
読んで分かったことは、ビジネスモデルの重要さは前々から理解しているけれど、ビジネスモデルの構築は楽しめそうに無いなということだった。興味がない。先月号の「意思決定」に比べたら記事への関心度合いは1/3〜1/5くらいだと思う。

それでも興味深い記事というのはある。
SoupStockTokyoなどを運営しているスマイルズの社長、遠山正道氏のインタビュー記事。
題名は『ビジネスモデルとは「やりたいこと」の確信である』。

遠山:ビジネスモデルを考えるうえで最大のカギは、収益性ではありません。主語はビジネスではなく、「やりたいこと」なのです。

ビジネスを進める上で必ずやってくる苦しい場面。このときに、「やりたいことをやる意義」が無いと、踏ん張れないし、苦しい局面を打開できないという。

ビジネスモデルから企画を考えると、前例を追うことになる。似たようなアイデアがポロポロでてくる。斬新なアイデアは前例がないからスルーされる。そんな企画会議や何とか会議を経験した人も多いのではないだろうか。
先に「やりたいこと」があって、それを駆動力としてビジネスモデルを構築する、という手順を私は正しいと思う。
だいたい「あれが儲かりまっせ」というモデルがあるならみんなやってるだろうし、ということはレッドオーシャンな訳で、どのみちそう簡単には儲かるわけねえんだ。
そんなことをするくらいなら自分たちの哲学を持ち、そこから「やりたいこと」を掘り起こして、苦しくても前に進むだけの「意義」を見つけることに集中した方がいいと思う。

私が考える「やりたいこと」の定義は、ただ単に「おもしろそう」「格好よさそう」ということではありません。世の中にインフラとして存在したときの意義まで、確信できるということなのです。それをビジネスとして成り立たせていくことが得意な人は、たくさんいます。肝心なのは、やりたいことが明確であり、そのことに確信が持てるかどうかなのです。

そんな私は、やりたいことは不明確だし確信も持ててないんですけどね。

先月号もおすすめです。というか先月号の方がおすすめ。

『グロースハッカー』

グロースハッカー

グロースハッカー

この本を読んで反省しているところです。
自分はまだまだ、努力も能力も不足していて、
今の仕事に対しても、
もっと改善できるところはあったんじゃないか、打つ手はあったんじゃないか。

そんなことが頭の中をよぎっていく。
やるべきことを放棄した結果、今の状態を招いてしまったのではないかと。

自分はいまディレクションとエンジニアを兼任していて、確かに実装に時間をとられてしまっているし、余裕がない部分もある。けれども、裁量は与えられているわけで、言い訳せずにもっと何かできたのではないかと思わずにはいられない。

この本におけるグロースハックのステップ1はポール・グレアムの言葉だった。

人が欲しがるものを作れ。

そもそもここを乗り越えないといけないのだけど。
乗り越えられなかった。
もしかしたら、ほとんどのプロダクトは乗り越えられないのか?

何にせよ、修行が足りません。