Posted on

compassからlibsassへ。gulpの設定を見直して大幅速度UP!

gulpを動かしてゴリゴリSCSSを書いています。

当社はPHPを主に扱っているので、PHPが動く環境でかつSCSSが書けてbrowsersyncが効く状態が一番ストレスなく開発が進められます。

そんなストレスフリーな環境を実現するには、gulpfile.jsのbrowsersyncの設定をproxyにすれば可能です。

gulp.task("default-toEccube", function() {
    browser({
        proxy: "xxx.xxx.xxx/project/"
    });
    gulp.watch("scss/**/*.scss",["sass"]);
});

ストレスフリーにらくらく開発を進めていた所、SCSSコンパイルに何秒もかかっている事に気づきました。

よくよくgulpfilesのSCSSコンパイルの所を見直してみると、compassがかなり時間をかける原因になっていたようでした。

gulp.task("sass", function() {
    gulp.src("scss/**/*scss")
        .pipe(plumber({
            errorHandler: notify.onError("Error: <%= error.message %>") 
        }))
        .pipe(sourcemaps.init())
        //.pipe(sass())
         .pipe(compass({
             config_file: './config.rb',
             css: css_path,
             sass: 'scss'
         }))
        .pipe(autoprefixer())
        .pipe(sourcemaps.write(css_path))
        .pipe(gulp.dest(css_path))
        .pipe(browser.reload({stream:true}));
});

このcompassはrubyで動かしていて、これがボトルネックの原因でした。

速くしたいならlibsassを使うような流れになってきているそうで、これまた導入しようと調べた所、実はコメントアウトしていた .pipe(sass()) がそのlibsassという事を知って二度驚きました…。

gulp.task("sass", function() {
    gulp.src("scss/**/*scss")
        .pipe(plumber({
            errorHandler: notify.onError("Error: <%= error.message %>") 
        }))
        .pipe(sourcemaps.init())
        .pipe(sass())
        .pipe(autoprefixer())
        .pipe(sourcemaps.write(css_path))
        .pipe(gulp.dest(css_path))
        .pipe(browser.reload({stream:true}));
});

すぐさま、compassを消去し、sassを復活させましたが、今度は自分が良く使うベースのscssファイル群にcompassの関数が使われているのがあって、コンパイルが通らなくなりました。

そこでcompassの関数をsassのみで使えるように開発された、compass-mixinsを導入してみました。

使用方法は、使いたいプロジェクトファイルのscssフォルダにダウンロードしたcompass-mixinsのcompassフォルダを入れて、インポートしたいscssファイル(例えば、styles.scss)の上の方に、

@import "compass/reset";
@import "compass";

で呼び出すだけで、エラーがなくなりcompassの関数が使えちゃいました!!

そして、コンパイルの速度は6秒から1秒未満に!ctrl-s押したらすぐ完了!みたいなレベルになりました。

スプライトなどをcompassで使っていた場合別の方法を取らないといけないですがそこまで使っていなかった方にはオススメです。

Posted on

jQueryを用いた気持ちのよいインタラクションとフェードインを考える

気持ちの良いデザインを考える

Webデザインについて再考する時間があったので、インターフェースの心理学やUI GRAPHICS等の本を読んでどんな事がサイトをデザインする時に人を魅了できるかを勉強してみました。

その中で、能動的に選んでいる気でいても、実は反応であったり無意識的に動かされている事が多いという事を学びました。

では、何をもって人は無意識的に動かされるか、という点で考えた時に「ユーザーが何か起こした事によって得られる反応(=インタラクション)を気持ちの良いものにする」事で、自然と楽しい気持ちになったり、もっと触ってみようという気持ちになって、より能動的な働きとして変えていけるんではないかと考えるようになりました。

インタラクションとは

例えば、ソフトウェア、各種製品、携帯機器、環境、サービス、ウェアラブルコンピューティング、組織自体などのシステムに適用される。インタラクションデザインは、人工物やシステムのユーザーへの反応を振る舞い(インタラクション)として定義する。IaD または IxD と略記されることもある。システム開発においてユーザーの人力操作に対するシステムからの適切な反応を設計することで利用目的に合致した両面転移や、グラフィカルユーザーインターフェース(GUI)要素の肖然な振る舞いをデザインする専門的な作業である。

引用:wikipedia

前述の「ユーザーが何か起こした事によって得られる反応」をインタラクションといい、システムにおけるView部分、Webサイトでいうリンクやボタンで表現される入力部分のみならず、画像や文字などの表示部分(視覚的に入力する)をより適切なデザインを施す事で、そのシステム自体をより良いものに見せるという点で、現在注目されている分野であります。

イマドキのWebサイトは、ボタンにマウスをホバーするとふわっと色が変わる事や、画像ギャラリーで画像が、自動的にスライドして見られるスライダーなど動的である事が標準となってきております。

jQueryやJavaScriptが持てはやされているのは、この「当たり前に動く」仕組みを実現するのに不可欠なプログラミング言語で、昨今では、HTML + CSSに加えて、JavaScriptができる事がデザインという分野で求められる傾向にあります。

気持ちいい画像の表示方法を考えてみる

前置きが長くなりましたが、本題はここからです。

「画像を表示させる」というWebサイトでは当たり前の事象についても再考してみました。以下のDEMOはAJAXにて画像データを取得して表示するサンプルですが、表示のさせ方を4パターン用意してみました。

※Chrome、Firefoxでの動作の確認をしました。

See the Pen AJAXを使った画像読み込みの一工夫 by koka (@kokaben) on CodePen.

画像を表示させる方法

画像は画像サイズによって表示までの速度がマチマチになる事や、画像データを取得している時でも他の作業ができるように、バックグラウンド読み込み処理を行いながら用意ができたものから表示させる非同期処理を用いるのが現在の主流です。

当サンプルでは、画像を裏で読み込ませてメモリに展開された時点で、表示させるという方法を用いております。

すぐ表示」ボタンは、別段処理を施さずに、用意できた順から表示するようになっています。

一番最速で表示させたい時はこの方法が良いですが、少し無骨に見えませんか?文字のみならばこの方法が一番良いかもしれませんがもう少し見せ方にこだわりたく思ってしまいます。

フェードインする」ではどうでしょうか。

少し気持ちよくなった気がしませんか?少しずつ表示される事で少しワクワクするようなそんな作用が引き起こされていれば狙い通りです!

ただ、これが何百件だとどうでしょうか。「これはいつまで、どこまで表示されるんだろうか」と多少不安になったり、遅延処理を行っているので「少し遅いな」と感じてしまうんではないでしょうか。

表示する量や、場所を選べば気持ちよさのみの印象を与える事ができそうです。

表示する数と領域をあらかじめ見せる

背景を付けて●●」のボタンが2つありますが、この手法は記事を書いている時期(2017年)によくみられる手法で、ボタンを押すとあらかじめ表示される領域の背景をグレーで表示され、そこに画像や文字を展開していく見せ方です。

この手法は、YouTubeのスマートフォン版を起動した時や、検索した時に見られたり、Googleの画像検索でスクロールしていった時に自動的に次の30件が表示される時に見られる手法をまねたものです。

背景を付けてすぐ表示」ボタンの動きを見てみましょう。

タイミング的には「すぐ表示」で画像が表示されるタイミングで表示されて、そこから0.5秒後に画像が表示されるので、実質は「すぐ表示」の時より遅いのですが、先に領域が出る事で「ああ、ここに何か表示されるんだな」と頭が認識する時間が発生するので、そこまで遅いと感じないのではないでしょうか。

ただまだ、無骨に思えるので、それにフェードインを加えた「背景を付けてフェードイン」を試してみて下さい。

気持ちよくないでしょうか?

領域が決まって、そこから画像と文字のフェードインが起きながら、文字の領域はフェードアウトさせる事で、安定感のある面白くて気持ちの良い見せ方になったのではないかと思います。

感性に訴えたい

以上のサンプルは、必ずしもそんな気持ちになるかどうかは別の話で、私は「そういう風に狙った」というだけな話です。受け手の気持ちは千差万別と思われます。

併せて思うのは使いどころを見誤ったり、要らない所まで動きを付けまくっていると見づらいページになってしまうので、使いどころを見定める事は必要と思います。「コレが利いてて気持ちいいんだよなー」くらいがちょうど良いと思っています。

オーソリティーに受ける方法というのを模索しながら、より面白くてコストパフォーマンスに優れた見せ方をこれからも模索していくぞーと考えながら、日々勉強していこうと思います。

Posted on

レスポンシブデザインのブレイクポイントを考える

昨今のHPデザインに置いて避けて通れぬ課題になりつつあるのが、スマホ・タブレット等でも、ストレスなく閲覧できるように可変レイアウトとするレスポンシブデザイン。
ひと昔前のように、「スマホ用サイト」を別に作る必要がないので、整備が楽(SEO的にも効果があるとか…)。

 

で、そのレスポンシブ機能でどうデスクトップだの、スマホだのを見分けているかというと、ズバリ、ブラウザの横幅である。
なので、デスクトップにてレスポンシブ機能を備えるサイトを表示して、ブラウザの横幅を縮めてみると、疑似的なスマホ閲覧ができるのである。(そんなことしてどうするのって話は置いといて)

 

さて、ここからが本題。

 

webページにレスポンシブ機能を持たせるにあたって、ブラウザの横幅のどの範囲をデスクトップ・タブレット・スマホと区切るかという話。
ちなみに、ブラウザを縮めていって、デザインが切り替わる起点となる横幅を「ブレイクポイント」と呼んでいたりする。

 

で、そのブレイクポイントの決め方、サイトによっても割といろいろあり、デスクトップorスマホの2択で区切っているところもある。
参考になりそうなのが、このサイト、StatCounter(http://gs.statcounter.com/)世界単位で使用ブラウザや使用端末の統計が見ることができる。もちろん、国ごとの絞り込みもできる。

 

例して、2017年1月~2017年3月の日本国内における、モバイル端末のメーカー統計がこれ。

Apple強すぎである。

 

与太話はさておき、下図が上から、2017年1月~2017年3月の日本国内における、デスクトップ・タブレット・スマホの横幅分布図である。

これを例としてブレイクポイントを決めていけばいいのである。

 

これを以て、今回自分は、ブレイクポイントを960px・600pxとしてみた。

 

ただ、スマホもタブレットも、大型化していく傾向にあるので、随時、ブレイクポイントの見直しは必要だと思われる。

 

書きながら、もしかしてこの数値はもう古いんじゃないのかと思いつつ、今日はここまで。

Posted on

Adobe Dreamweaver CCを使って爆速でSASS(SCSS)環境を手に入れる

私はCSSを書く際には、主にSCSSを使用しています。

要素を入れ子にできるので、可読性が高く、コンポーネント的な考え方でCSSを組む傾向がある今日では、フロントエンド界隈ではとても重宝されています。

ここ最近までSCSSは、GruntやGulpなどのターミナルやコマンドプロンプトで動くタスクランナーの力を借りて使う事が主でしたが、Adobe Dreamweaver CC (2017)で標準機能として採用されたので、黒い画面とにらめっこする事なく使えるようになりましたので、敷居は随分下がったのではないでしょうか。

とっても簡単に導入できるので、その導入方法をここに記しておきます。

続きを読む Adobe Dreamweaver CCを使って爆速でSASS(SCSS)環境を手に入れる