World of granshe.

[1] [2] [3] [4] [5] [6] [7]

[PR]

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

2025/01/22 (Wed)

CSS Nite LP35「マルチデバイス対応 2014」に行ってきた

気付いたら半年以上ご無沙汰していました･･･。生きてます。

ひさしぶりにセミナーに参加してきたのでレポートを書いてみます。とてもざっくりと。

基調講演：スマホサイトの今、スマートデバイスのこれから

たにぐちさんのお話ははじめて聞くのですが、とてもお話がわかりやすく、スッと脳内に入っていく感じでした。

技術は日々進歩し、新しい端末が出て、回線も早くなっていくわけで、そういった未来が確かにあります。

パフォーマンスだいじだよ。サイト軽くしようよ。と言ってみても、「今はLTEでてるよ？」とか、「コレが増加するとどれくらい重くなるの？たいしたことないよね」みたいな発言に対し、うまく説得できない自分がいたんですが。
（「表示が速くて悪いことはない」という名言も、実際には届かないことが多い）

今、最新端末より1世代型落ちの機種を使った、格安スマートフォンが相次いで発売されている。 Appleはそういったことはしないので、それらは無論Android端末。そして、それらはスマートフォンを持っていない、アプリなども使いこなす必要がない一般の人向け。それらの回線は、総じて遅い。

新しい端末が出ても、しばらくは古い端末が回線も遅いまま、供給され続ける。そうやって、安いAndroid端末がこれから増えるのではという予想。

自分が想像していた未来とは全く違う視点にとても驚かされたし、今回のイベントの中で一番「すごいや！」と目からウロコだったのはこの基調講演でした。

レスポンシブWebデザインのワークフロー

とてもわかりやすい内容でした。RWDやりたての方には、とても学ぶことの多いお話だったと思います。

RWDはウォーターフローよりはアジャイルが向いてる。分業している場合は、コーダーは上流工程にまで関わることでうまくいくよ。それぞれの職域を越えていこうね。というお話。

自分個人としては、自分が思っていること、考えていることをそのまま代弁していただいたような感じで、「自分の考えてることは間違ってないんだ」「方向性はコレでいいんだな」と再確認できました。

ブレークポイントについても触れられていて、自分としてもブレークポイントについては最近言いたいことがいっぱいあるので（他のブログでも示唆されてるような二番煎じ的な感じですが）いずれ機会があれば･･･。

マルチデバイス対応な実案件で使う、Bootstrap のすゝめ

自分はBootstrap否定派だったのですが、あぁ、そう使えばいいのね。なるほどねー！と感じました。

ただ、『最初っからBootstrap使わない想定だと無理だね。』というところがハードルが高くて。心が折れちゃいました。
弊社はほぼ分業制で、これでワイヤー書いてね、みたいなテンプレートが既にあるので、なかなかここが難しいんだな･･･と。

フレームワーク系は『class名がセマンティックじゃないからやだよ』と思っていたのですが、Sassのextend使えばclass名好きに指定できるよね！というお話をされていてなるほどそれはそうだなぁと思いました。

スマートデバイス時代のJavaScript

ちょうど案件でzepto.jsを使おうと思っていたので、タイミングがとてもよかったです。

強いて言えば、最近TypeScriptに興味があったので、TypeScriptについてもう少し詳しく説明いただけると嬉しかったが･･･ここまでの流れから、たぶん今回のセミナーは初級者向けっぽいな、という流れだったので、あきらめて涙をのむ。

jQueryでJS書くのが当たり前になっているけど、スマートデバイスの回線のことを考えると、ほかのライブラリについても考えていいんじゃないか？プリプロセッサ使ってもいいしさ！という内容。

個人的にはセッションで紹介されていたvanilla.jsが非常にツボりました。すごいぜvanilla.js！！
･･････勉強します｀；ω；´

あと、Angular.jsも勉強してみては？というコメントを聞いて、勉強しようと思いました。
ホント、最近現場離れ気味なので、技術系疎いっす･･･。

UI設計に役立つ！意外と知らないiOS/Androidの流儀

Androidと、iOSの仕様の違いを比較しながら解説されていたプログラムでした。

基本的には、仕様書の中での2つのOSの差異を、対談しながら拾っていった感じでした。

一番印象に残ったのは、「Pure Android」という項目がAndroid側のガイドラインにあること。
「他のOS（iOSやWindowsなど）の概念を持ち込まないでくれ」というのが明示されているそうです。
わざわざ記載されているのはiOSのアプリのインタフェースがAndroidアプリにそのまま持ち込まれがちで、統一感がなくなってしまった経緯があるからだとか。

トラブルシューティング 2014

登壇したお二人のかけあいが面白くて楽しく聞けました。ちょっと会社を見学してみたくなりました。

セッションの本題ではないものの、やっぱりGrunt（タスクランナー）すごいなというのが感想でした。
メディアクエリーの記述をひとまとめにしてくれるcombine-media-queries。
あとはセッションで直接紹介されてはなかったけど、プロパティの記述順を整理してくれるcsscombや、もはやデフォルトになっているauto-prefixerやlivereloadX。

Gruntは導入のハードルが高くて、なかなか前に進めなかったんですが、これはやってみないといかんな。。。とあらためて実感しました。

あとは、最後のほうに紹介されていたpleeease。
ポストプロセッサとプリプロセッサの違いがわからなかった自分はこちらの記事で勉強しました。 CSSポストプロセッサー時代の到来

所感

セミナーの内容としてはわりと初級者向けの内容で、参加したことに後悔はしていませんが、自分にとっては物足りないといえば物足りないというか。フォローアップ参加だけしていても元は取れたような気はします。

ただ、今回はちゃんと名刺を持って行ったこともあって（前回は仕組みがわからず持っていかなかった）、コミュ症の自分にしては幸運にも、お近くに座っていた数名の方と少しお話しすることができました。それはセミナーに参加しないとできないことだったので、自分にとっては大きな収穫でした。

制作会社のなかではわりと大きめの規模な会社に勤めていることもあって、社名をご存知の方も多く驚きました。（自分はポンコツですが

最近、わりと会社の上流の部分に顔を出すことが多くなったので、会社の仕組みとか具体的に説明することができるようになった自分がおり、「コーディング楽しいよね！会社のこと？おっきいかいしゃだし上の人が考えてることはわかんないです☆」みたいな受け答えをすることもなく、自分、大人になったなぁとしみじみしたりしました。

ということで以上になります。
今後はもうちょっと頻繁に記事を書いていきたいですね。。。
ネタはぽつぽつあるんですが、なかなかまとめきれないです･･･（涙

2014/06/15 (Sun) Web制作全般 Comment(0)

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の特長をほぼ知らなかったので、勉強になりました。

2013/09/29 (Sun) Web制作全般 Comment(0)

わたしの作業環境：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ファイルをまとめて結合してくれます！素敵！

結合したいファイルの頭にはアンダースコア「_」をつけます。
（CSSファイルとして出力されることはなくなります）
basic.scss（出力ファイル）のほかに、_base.scss、_modules.scss を作ります。
basic.scssに下記の記述をします。（アンダースコアは除いてOKだそう。
```
@import "base", "modules";
```
書き出すと、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を再計算してくれます。
便利ですね！

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

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

2013/09/22 (Sun) Web制作全般 Comment(0)

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もマークダウンで書いてしまいたくなります（笑）ぜひおためしくださいませ。

2013/07/15 (Mon) Web制作全般 Comment(1)

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

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

2013/04/07 (Sun) Web制作全般 Comment(1)

<< 前のページ次のページ >>

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	31