忍者ブログ

World of granshe.

HTMLやCSS、JavaScriptに関する話題を中心に、Web制作について知ったこと、覚えておきたいことをメモしておく個人的スペースです。
[1] [2] [3] [4] [5] [6] [7

[PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

CSSプリプロセッサについて~Sass、LESS、Stylus

すいません、『わたしの作業環境』シリーズでつなげようと思ったんですが急遽気になるネタを見つけてしまって。

CSSプリプロセッサ(CSS拡張メタ言語)広まってきて久しい?ですが、有名どころはSass、LESS、Stylusだと思います。
サーバサイドがどうとか、環境が必要とか、インストールに関する内容はなんとなく知ってはいるのですが、
具体的な機能や文法の違いを明確に知らなかったので、ふと検索してみると私にぴったりのスライドが見つかりましたので抜粋して紹介したいと思います。

毎度のお断りで恐縮ですが、超意訳です。
詳細はぜひ、本家のスライドをご覧くださいませ。英語わからなくても、コードが書いてあるので読みやすいスライドだと思います。
CSS PreprocessorsSass, Less and StylusPatrick Arlt - @patrickarlt


で、結局どれがいいの?

という問いに、@patrickarltさんは
端的に言えばSassかStylus』。丁寧に言うと
Ruby使ってんならSass。Node使ってんならStylus。コマンドライン(いわゆる「黒い画面」)が嫌いなやつはLESSな。
とのこと。

どう違うの?

Sassの特徴

  • @extend → クラス名は違うけど、ベースのスタイルが同じときに、2回同じコードを書くのはめんどくさい。それを簡単にするのが@extend。
  • @media → mediaqueryをセレクタの中に書ける!
  • @content → 自分が使いこなせてない機能なので説明が難しいですが、ある条件ではこのスタイルをあてたいけど、という条件分岐に容易に対応できるものだと思います。
  • Compass → 言わずもがな。

LESSの特徴

  • Mixins → CSSのプロパティを記述する場所に、CSSのクラス名を指定するだけで、そのクラスのスタイルが読み込まれる。(変数として格納する必要なし)
  • Namespacing Mixins → CSSとLESSのクラス名のかぶりを防ぐのに使える機能みたいなのですが、使える場面がぱっと場面が浮かびませんでした・・・。
  • Scoped Variables → CSSのセレクタ内で変数の上書きができる。
  • クライアントサイドでコンパイルができる。(使用時にRubyやNodeのインストールが不要)

Stylusの特徴

  • CSSの記述に必要なコロン「:」、セミコロン「;」を半角スペースで代用できる
  • forループやif文などを用いた条件分岐をプログラミング言語に近い感じで行える。
  • CSS3のキーフレームの実装がとっても楽
  • APIでいろいろできるらしい(すみません、曖昧で。。。)
  • Nib → SassでいうCompassみたいなもの。

自分はSassしか使ったことがなかったのですが、
Nodeをインストールしてるので、Stylusはありかもなぁと思いました。
日常的にCompassやNibの機能を使いこなしてるような人だと、たぶんLESSに戻るのはつらいのかなぁと。
LESSでもCompassやNibにあたるものはないという認識なんですが、存在するんですかね。。。

MacユーザーはデフォルトでRubyが入ってるので、Sassへの敷居は低いかもしれないですね。
自分は会社でも家でもWinユーザですが、周りでもやっぱりRubyのインストールにてこずる人は多いので。

LESSとStylusの特長をほぼ知らなかったので、勉強になりました。

PR

わたしの作業環境:Sass&Compass編

お疲れ様です、完全社畜と化しております。
でもそれには理由があって、今後のために「今」必要だという、自身の判断でやっています。
なので、今までのキャリアの中では、仕事量に比べて、精神的には非常に前向きに仕事ができてます。

ということで、ネタとしては今さら感満載ですが、
最近作業環境をガラッと?変えました。
今度社内勉強会に向けてまとめようと思ってるので、事前にここに書いてみます。

一応サブタイトルとして
「Sass&Compass+Sublime+LiveReload」ってついてまして(自分の中で)、
3本立てでお送りする予定です。

時間がなかったので、とりいそぎSass&Compassから。

Sass&Compass

今回の隠れサブタイトルの中で最初に導入したものがコレです。
最初は、「CSS3のprefixをつけてくれる便利なやつ」だと思ってたのですが、
それだけじゃない。
そして今も、きっとこんなもんじゃない。まだ使い切れていない何かがある。と思ってます。

ちなみにSassとCompassインストールしている前提で、自分がどういう機能を使っているのかを書いています。
自分は下記サイトを見てインストール含め基本的なところを学びました。

前準備

自分はいつも下記の指定を最初にしています。

@import "compass"; // compassを使うときの指定です。たいてい使います。
$experimental-support-for-svg: true; //IE9でgradientしたいときは必ず。

機能1:入れ子

個人的には最近はあまり使わないですが、CSSを深い入れ子にするときにSassは便利です。

Sassなし

#container{
max-width:960px
}
#container .hdg01{
font-size:
}
#container .txt01{
line-height:1.5;
}
#container .txt01 a{
color:#9cf;
}

Sassあり

#container{
max-width:960px;
  .hdg01{
  font-size:1.25em;
  }
  .txt01{
  line-height:1.5;
    a{
    color:#9cf;
    }
  }
}

Sassではこんな感じで書けます。

入れ子でCSSを書くのがあまり好きではないのと、
インデントがあまり好きではないので、最近はあまり使わなくなりました。
(インデントしなくても書けるんですが、読みづらい

機能2:import

一昔前に、@importでCSSを1ファイルにインポートするのが流行ってませんでしたか?
私もやってました。
その後、@importだとパフォーマンスが悪いということで、CSSは@importせず、直接1ファイルで読み込むのが主流になりました。

私自身、大きなサイトを作ることがあまりなかったので、スタイルを1ファイルでさせることに対して、苦労はほとんどなかったのですが、
最近、CSSを大量に書く機会が増え、コードを探しにくくなってきました。
そこでimport。

この記述を書くと、sassが勝手にCSSファイルをまとめて結合してくれます!素敵!

  1. 結合したいファイルの頭にはアンダースコア「_」をつけます。
    (CSSファイルとして出力されることはなくなります)
    basic.scss(出力ファイル)のほかに、_base.scss、_modules.scss を作ります。
  2. basic.scssに下記の記述をします。(アンダースコアは除いてOKだそう。
    @import "base", "modules";
  3. 書き出すと、basic.css内に、_base.scss、_modules.scssの内容が出力された状態になります。

管理は複数ファイルだけど、最終的に出力されるCSSは一つになるので、便利。
複数人で設計をする際も、マージの心配をせず作業することができますしね。

機能3:Mixin

良く使う機能をmixinとして保存しておくことができます。

たとえば自分が良く使うのは、これ。

@mixin iAbs {
content: "";
display: block;
position: absolute;
}

擬似要素をbefore&afterでアイコンをつけるとき用のmixinです。

IE8以上対応の案件ですと、私はsprite+before&afterを多用します。
毎回登場するたびにスタイルを書くのが苦痛だったのですが、mixinを使うと指定が楽にすみます。

Mixinなし

.xxx:before{
content: "";
display: block;
position: absolute;
top:10px;
left:0;
}

.xxx:after{
content: "";
display: block;
position: absolute;
top:50%;
right:0;
}

.ttt:before{
content: "";
display: block;
position: absolute;
top:10px;
left:10px;

記述場所がくっついていればいいんですが、いろんな場所で使ったりするので、コピーしてくるのが大変です。
そこで、mixinを使うと、こうなります。

@mixin iAbs {
content: "";
display: block;
position: absolute;
}

.xxx:before{
@include iAbs;
top:10px;
left:0;
}

.xxx:after{
@include iAbs;
top:50%;
right:0;
}

.ttt:before{
@include iAbs;
top:10px;
left:10px;
}

楽ですね!

他にも、色をmixinでストックしておけば、
サイトで使われている配色を少し変えたいときも、1箇所に色の指定をまとめておけば、
置換することなく、変更することができて便利なのです。

機能4:自動prefix

Compassを使うと、自動でprefixを生成してくれます。
現状、自分が使っているのは下記。です。

@include box-sizing(border-box);
@include background-image(linear-gradient(#efefef 0%, #dfdfdf 100%)); 
@include rotate(-45deg);

機能5:Sprite

CompassにはSpriteを簡単に生成してくれる機能があります。
一度使うと、これなしでは生きていけなくなります。

使い方(設定
$icon-spacing:2px; // 生成されるsprite画像の、画像同士のスペースです。
$icon-sprite-dimensions:true; // sprite内のアイコンの幅・高さを出力します。
@import "icon/*.png"; // iconフォルダに入ったpng画像をsprite化する、という指定です。

Sass側で、画像の出力先を指定することができます。
Sassのconfig.rb内で

images_dir = "shared/images"

と記述していた場合、sprite画像は「shared/images」配下につくられます。

その出力先のフォルダ内に、sprite用の任意の名前のフォルダを作ります。
上の例でいくと、「icon」というフォルダです。

@import "icon/*.png"

sass側の画像の出力先「shared/images」からの相対パスを記述します。

このフォルダの名前は任意で変更できます。sprite画像を複数作る場合は、下記のように指定します。

$icon-spacing:2px;
$hdg-spacing:2px;
$icon-sprite-dimensions:true;
$hdg-sprite-dimensions:true;
@import "icon/*.png";
@import "hdg/*.png";

これらの指定をして、iconフォルダに、spriteしたい画像を入れていきます。

これをコンパイルすると、自動でに結合してくれます。
結合したファイルの名前は、フォルダ名と同じになります(この例の場合、icon.png)

なお、普通にspriteを作ると、ランダム文字列が生成されます。(キャッシュ対策?)
これを消したい場合は、下記のような指定をconfig.rbに追記します。

# Make a copy of sprites with a name that has no uniqueness of the hash.
on_sprite_saved do |filename|
  if File.exists?(filename)
    FileUtils.cp filename, filename.gsub(%r{-s[a-z0-9]{10}\.png$}, '.png')
    # Note: Compass outputs both with and without random hash images.
    # To not keep the one with hash, add: (Thanks to RaphaelDDL for this)
    FileUtils.rm_rf(filename)
  end
end
 
# Replace in stylesheets generated references to sprites
# by their counterparts without the hash uniqueness.
on_stylesheet_saved do |filename|
  if File.exists?(filename)
    css = File.read filename
    File.open(filename, 'w+') do |f|
      f << css.gsub(%r{-s[a-z0-9]{10}\.png}, '.png')
    end
  end
end

また、画像をひとつにまとめてくれるだけじゃなく、CSS側での指定も自動で行ってくれます。

Sassの記述

nav a:after{
content: "";
display: block;
position: absolute;
top:10px;
left:0;
@include icon-sprite(arrow1);
}

// ※さっきのmixinを記述すると、もっと簡単に。
nav a:after{
@include iAbs;
top:10px;
left:0;
@include icon-sprite(arrow1);
}

出力されるCSS

nav a:after {
  background: url('/shared/images/icon.png') no-repeat;
}
nav a:after{
content: "";
display: block;
position: absolute;
top:10px;
left:0;
background-position: 0 -39px;
height: 11px;
width: 11px;
}

画像ファイルが増えても、background-positionを再計算してくれます。
便利ですね!

こういうのは実際に動いてるの見せないと、なかなかやってみようかなっていう気にならないですよね。実際にはライブコーディングでやれたらなぁと思ってます。

別に、「みんなこれ使えよ!」ってわけじゃないですけど、こーいう便利ツールを知ってると、楽しくなるよ、ということは伝えたいです。

Markdownで記事を書く、データベース不要のCMS、Picoを使ってみた

だいぶご無沙汰しておりました。
久しぶりに自分のブログを見に行ったら広告が出現していて震えました。 前回から3ヶ月も経っていたとは。。。

激務に激務を重ね、ようやく落ち着いてきたので、広告消すためにも記事を。

案件が落ち着いてきたというのもあり、今までまわりになかった技術に手を出すようになり始めました。
今さらながらSublime Text2を使ってみたり、Emmetをつついてみたり。Markdownについても最近触れる機会が多く。

そんなときに、Markdownでコンテンツを記述する、データベース不要のCMS『Pico』なるものを見つけたので、今回ご紹介いたします(通販風)。


Picoとは

本家サイトはこちらです。→Pico
すっげえシンプルで、(DBを使わないので)表示がめっちゃ早いCMS。Webを簡単に作れるぜ!(超意訳)
とのこと。

特長は、データベースがなく、テキストをマークダウン形式で書くところ。
ヘッダーとフッターとサイドナビをPHPで自動で付与します。編集も可能です。
URLのルールとかはPico本家のドキュメントを見てください(割愛)。

ファイルはマークダウン形式(拡張子は「.md」)で生成して、直接サーバ上に置きます。
簡単にファイルを作成できるプラグインは後ほどご紹介します。
あ、データベースは必要ありませんが、PHPは必要です。PHP 5.2.4以上のバージョンが必要です。

自分は、Twitterでお気に入り登録した記事が埋もれて探せなくなるのを救出するために、
まとめリンク集をためしに作ってみました。(まだ調整中ですがフライングで


導入方法

1.ダウンロード

Picoダウンロードページから、Downloadボタンを押してファイルを取ってきます。

このタイミングで、同時にプラグインも落としました。
Picoプラグインページから、お好みのプラグインを取ってきます。
自分はあまりRSSに興味がなかったので(ブログとして使う想定ではないので)RSSは除き、それ以外の二つはダウンロードしました。
以降は、上記プラグインをダウンロードした前提で話が進みます(汗)。すみません。

2.サーバにアップ

PicoはPHP 5.2.4以上がサーバにインストールされている必要があります。

PHPのバージョンを確認したら、Pico-masterの中身をお好きなディレクトリにアップします。
ダウンロードしたプラグインは、Pico本体の「/plugins/」ディレクトリの中に入れてください。

Pico Editorというプラグインは、入れるとWeb上でMarkdown形式で記事を記載&プレビューでき、自動でファイルを保存してくれるのでぜひ入れることをオススメします。

3.Pico Editorの設定

Pico Editorをダウンロードしたら、フォルダ内にある「pico_editor_config.php」を開きます。
任意のパスワードを設定してください。(何でもかまいません。)
パスワードはそのまま指定するのではなく、ジェネレータで変換したものを入れてください。

パスワードの設定が終わったら、Pico本体のpluginsディレクトリの中にアップします。

アップが終わったら、アップロードした場所のURLの後ろに /admin/ を入力すると、ログイン画面が開きます。
先ほど設定したパスワードを入力して、ログインします。

ログインすると、デフォルトのファイルが3つほど表示されていると思います。

何度か試してみたのですが、どうもこのエディタは、エディタ上で作られてないファイルは編集も削除も出来ないようです。
なので、デフォルトのファイルに関しては、エディタからではなく、サーバ側から直接削除します。

わたしは、Pico本体の「/content/」フォルダの中に入っている「/sub/」ディレクトリ配下の.md ファイルを削除し、
Pico本体の「/content/」フォルダの直下に入っている「index.md」をテキストエディタで編集してトップページを作りました。

4.サイトの設定

サイトのタイトルを編集するには、Pico本体のルートフォルダにある「config.php」を修正します。
初期状態では全てがコメントアウトになっている状態なので、 タイトルを変えたい場合は、
$config['site_title'] = 'Pico';
をコメントの外に出して調整します。

ヘッダーやフッターなど、共通部分のHTMLを変更したり、スタイルを変えたい場合は、
「/themes/default/」のHTMLとCSSを直接修正するか、
あたらしく「/themes/」ディレクトリにテーマ用ディレクトリを作成し、「config.php」に
$config['theme'] = 'ディレクトリ名'
を指定してください。

5.Pico Editorを使って記事を追加

http://アップロードURL/admin/ にアクセスし、ログインして記事投稿画面に遷移します。
画面の左側上部にある「+」マークでページを追加します。

ページ追加のコツですが、2点あります。

  • please enter a post titleの画面では、ファイル名(英数字)を入力すること。
  • 新規作成すると、テキスト内にコメントで「Title:」と入っている部分があるので、そのファイル名を日本語に変更する。

そうすると、ディレクトリ名は英数字になり、サイト内のメニューとしては日本語が表記されるようになります。

エディタの右下に「目のマーク」があるのですが、これを押すとマークダウンされたものが簡易的にプレビューされます。

文字を入力していると、画面右上に「Saved」というアイコンが出ますが、
このエディタでは情報はリアルタイムにセーブされます。

「Saved」というアイコンが出る前に別のページに遷移しようとすると、
「セーブしてないからデータ消えるよ?いいの?(実際は英語)」とアラートが出るので、キャンセルを押して、
しばらく待つか、適当に文字を入力してみるか、「目のマーク」を押してプレビューしていると「Saved」が出るので、セーブされたことを確認して別のページに移動してください。
セーブまでには若干のタイムラグがあります。

ちなみに、Pico Editorを使わなくても、「ファイル名.md」でファイルを作成して保存し、
「/content/」ディレクトリ配下にFTPでファイルをアップロードすれば、ページを作ることは可能です。


一度セッティングが終わって使い慣れれば、かなり楽です。
セッティングするまでと、軌道に乗るまではだいぶ大変かもしれませんが・・・(笑

自分が主につまづいたポイントを整理します。

  • アップロードしたけど、トップページが表示されない。
    →PHPのバージョンが足りていなかった。
  • Pico Editorで記事が編集できない。
    →Pico Editorで作成したファイルでないと、編集が出来ないようです。(デフォルトで入っているファイルは編集できない)
  • Markdownの記法を忘れた。
    Markdownの文法はこちら

一度マークダウンに慣れると、HTMLもマークダウンで書いてしまいたくなります(笑) ぜひおためしくださいませ。

レスポンシブWebデザインにおけるコーダーの役割

先日、Twitterで
『レスポンシブWebデザインをする際に、ナビゲーションなどをPC用とSP用の2種類、HTML内に書いて、出し分けることがあるようだ』
というようなことをつぶやいたのですが、自分では思ってもいないところでリツイートされました。

自分はちょっとした愚痴のつもりで書いたのですが、これはもうちょっと深く考えるべき問題なのかもしれない。と感じ、
自分なりにもうちょっと考察して、人と話して、自分なりの答えが見つかったので書いてみます。



私の周辺では、レスポンシブWebデザイン(以下、RWD)の案件をやるとき、「PC用」「スマホ用」2種類のデザインをお客さんに提出し、それをベースにコーディングすることが多いです。
PCサイトとスマートフォン最適化サイトを両方作るのと同じような手法です。
いわゆる「スマートフォン最適化」では、PCとスマホ用のHTMLは別で作れますので、デザイン上の制約はあまりありません。

でも、RWDは1つのHTMLを複数のデバイスにうまくフィットさせるための技術。
「PC用」「スマホ用」に別で作られたデザインを、1つのHTMLで実装する、ということではありません。
冷静に考えれば、2つの異なるデザインを1つのHTMLで実装しようとすること自体、不可能ではないでしょうか?

でも、RWDというあたらしい手法が誤解され、免罪符として使われ、
「RWDだからしょうがないんだろうな」と言って、
「PC用」「スマホ用」で、どう考えても1ソースで組めないようなデザインでも、 HTML内に複数回要素を繰り返して、mediaqueryでウィンドウ幅によってdisplayを切り替えて実装してしまう、という例があるようなんです。

マークアップエンジニアとして普通に考えたら、
HTML内に同じコンテンツを2回繰り返して、それをdisplayで表示切替する、なんていうのはありえない手法です。

それが、なんだか『角丸実装するのに不要なdivちょっと入れようかな。仕方ないけど。』くらいのレベルで、
同じコンテンツをHTML内に複数回入れることが行われていたんです。

『デザインはもう変えられないから、仕方なくやった。』

という理由で。

これは、今まで、弊社が主に「分業」で案件をすすめてきたことに起因していると考えています。

  • ディレクター、デザイナーは、コーディングの技術的な部分に関してはあまりよく知らない。
  • コーダーはデザインに関して、あまり積極的に関わらない(受身)。

だから、コーディング可否の判断がされないデザインがあがってきて、
「デザインは絶対に変えられないもの」だと刷り込まれたコーダーはそのまま組む。
という図式になってしまっている。

従来のWeb制作ならそれでもよかった(よくはないけど)。
ただ、「RWD」という1つのHTMLで実装しなければいけない案件で、「PC用」「スマホ用」の複数パターンのデザインが上がってくる現状を考えると、
この図式なら『デザインはもう変えられないから、仕方なくやった。』
ということになるのは必然かな、と感じる自分もいました。

それを、
『ディレクター、デザイナーが技術的なことを知らないから、悪いんだ!』
『自分はコーダーとしてがんばってる、何も悪くないんだ!』

と結論付けるのは簡単ですが、上記の考えではおそらく、何の解決にもなりません。
なぜなら、あまりに「他力本願」だからです。

ディレクターがもっとRWDについて学べばいいんだ、デザイナーがCSSをもっと学ぶべきなんだ、
という意見は正しいし、本来ならそうすべきでしょう。
でも、「他人を変える」のは非常に難しいことなんです。

何かを変えたいとき、その一番の近道は「自分が変わる」こと。
だから、「自分(コーダー)がどう変わったら解決するのか?」を考えました。

じゃあ具体的にどうするのか?

コーダーがデザインすればいい』んです。

作業フローはこうです。

  • ベースのデザイン(これがPCかスマホかは決めの問題だが、とりあえず1枚)をデザイナーに作ってもらう。
  • ベースのデザインを元に、コーダーがmediaqueryで動きを作っていく。
  • それをデザイナー、ディレクターにプロトタイプとして出して、動きのレビューをしていく。

よくよく考えれば、
そもそも「レスポンシブWebデザイン」で、「PC用の見た目」「スマホ用の見た目」をデザインすること自体がおかしいのですから、ベースのデザインテイストだけデザイナーに作ってもらって、それ以外は全部コーダーで巻き取ってしまえば、全てうまくいくのです。


今までコーダーは、デザイナーの作ったデザインを、そのまま組めばよかった。
基本的にデザイナーはコーダーに相談せずデザインをしていたし、
コーダーがデザイナーに意見を言うこともほとんどなかった。

でも、上記のフローでは、 デザインのベースはデザイナーが作るけれど、それを「アレンジする力」がコーダーに求められます。
コーダーがデザインについて学び、他のサイトの事例について勉強する必要があります。

『そこまでコーダーがやるの?』と思う人もいるかもしれません。
もし『ディレクターやデザイナーに勉強させる』ことが出来るなら、やらなくてもいいと思っています。
でも、「他人が変えられない」なら、「自分が変わるしかない」んです。


それに気づかされて、正直「怖い」と感じた自分がいました。
「デザインをやりたい」と思いながらも、デザインすることから逃げて、
結局デザイナーに全て任せて、デザインを見て、「これはできません」と言っている自分がいたことに気づいたんです。

年齢が上がるにつれて「変化」することをためらうようになる、というのは感じていましたが、
自分自身が無意識のうちに、抵抗していたんだということに気づきました。

コーディングの知識だけじゃなくて、UIやIAの知識や、他のサイトのデザインを収集して、自分の仕事の幅を広げる。
今までマークアップしかしてこなかった自分には、かなり大きな変化です。
でも、むしろこれが出来るようになれば、コーダーとしての自分のワクが広がるのではないか。
そう考えたとき、自分がずっと感じていた、「コーダーってこの先あるんだろうか」という漠然とした不安が、すっと晴れた気がしたんです。

年齢を重ねるにつれて、「変化」するために必要なエネルギーは大きくなります。
でも、自分は恐れずに「変化」していきたいと、改めて思いました。




美容師さんとWeb屋

今日、半年くらいぶりに(汗)髪を切りに行ってきました。
いつも家の近くのお店に行っていたのですが、そこがつぶれてしまっていたので、別のお店に行くことにしました。

自分は残念ながらお洒落さんではないので、とくにこういう髪形がいい!という信念はなく、
ただ、せっかく金出して切りに行くんだから雰囲気はちょっと変えたいけどどんな髪型が合うのかよく分からないしなー。
『お任せで』ってできたらそれが一番いいなー
と思っていました。

実際にお店に行きますとお兄さんが対応してくださいました。
どんな感じにしましょうか?と言われて本を渡されました。

渡されたのはよかったんですが自分にどんな髪型が似合うのかさっぱりだったのでとりあえずめくってみるレベルでしたw


お兄さん(以下、兄):
『長さはどうしますかー』

私:
『短いと顔に当たって肌が荒れるので(まじめに)肩より下のほうがいいですねー』
(本をめくりながら)

兄:
『普段ブローとかしないのであれば、肩くらいにしちゃうと髪の毛がはねやすいかもですね』

私:
『じゃあもうちょっと長いところでお願いします。』

兄:
『では7センチくらい切る感じですねー』

私:
『あと、量が多いので少なくしたいです』(既に本は見てないw)

兄:
『少なくするにはレイヤー?(うろ覚え)を入れる必要があるんですが、あまり入れすぎると髪の毛を結ぶときにサイドが落ちてきちゃったりします』

私:
『なるほどー髪の毛結ぶときに落ちちゃうのはちょっと嫌ですね』

兄:
『じゃあ、下のほうだけ軽くレイヤー?を入れてみましょうか。これだったら結ぶときに落ちることもないと思います』
(本をめくって、こんな感じで、と示す)

私:
『じゃあそれでお願いします(笑)』


自分自身、
『お任せでってできたらそれが一番いいなー』
などと思っていたくせに、実際にいろいろ聞かれると注文がたくさんあるじゃねーかと軽くあきれました(笑)

そして、Webでもおんなじことが言えるんじゃないかなーと思ったのです。


お客さんの中には、絶対こういう感じのものがいい!という明確なビジョンを持った人もいれば、自分みたいに、なんとなく雰囲気変わればいいかなーという、曖昧な方もいるわけです。

仕事をしていて、
『おたくプロなんでしょ?提案してよ。』
みたいなことを言われた、と聞いたことがあるのですが、
まぁ、まさにそのとおりだなと思いましたよ。

プロだったら、お客さんがどういうシーンでそれを利用していて、
どういう風に使っているのか、知った上で、提案をする必要があるんです。


お客さんはWebについてよく分からないから、いろいろ言ってくることもあると思います。
私たちは、Webについてはお客さんよりもずっと知っているはずです。
でも、お客さんのこと、お客さんのお客さん(エンドユーザー)については、お客さんのほうが知っています。

お客さんがどういったクライアント(またはユーザー)を抱えているのかきちんとヒアリングして、
『そういったユーザーが多いなら、このようにすれば良いと思います。』と提案したり、
お客さんからのリクエストに対し、『ユーザーのことを考えるとこのようなデメリットもありますが、それでもやるんですか?』
といった、デメリットもきちんと伝えられるようになって、
やっとWeb屋やってるって、言えるんじゃないだろうかと思いました。

私は制作という立場なので、自分の技術が、Webサイトにどのような影響をもたらすのか?
どんなメリットがあり、デメリットがあるのか?費用対効果はどうか?
ディレクターに説明するのがプロとしての仕事だということ。


本当に当たり前のことで、何度も言ってるんですけど、
自分のことよりも、お客さんのことよりも、まずユーザーのことを考えるべきで。

私たちの仕事は、Webを作るのがメインじゃなくて、
お客さんに何か良い影響を与えられるようにするのがメインで、
じゃあ何を使っていい影響をもたらすのかっていうツールがWebなだけなんだなー。
と、あらためて思いましたよ。

ということで、結論としては、前回の投稿と同じ感じなんですが(汗)

美容室行っただけなのになんだかすごい人生勉強になって、書かずにはいられませんでした。

プロフィール
名前: ゆーり
職業: コーダー(模索中
趣味: Web制作
自己紹介: 某Web製作会社の入社5年目のマークアップエンジニア。専門はHTMLとCSSとMT(自称)。
カレンダー
03« 2017/04 »05
S M T W T F S
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
ブログ内検索
忍者ブログ [PR]