WEBディレクターの仕事のスピードを格段に向上させる、ワイヤーフレームの作り方。

最近、コーディングよりも企画側の仕事が増えてきたように感じます。どんな仕事でも言えますが、考える事に最大限の時間を使って、アウトプットにかける時間はできるだけ最小限かつ、安定したクオリティを求めたいものです。

ワイヤーフレームの作成は色々試行錯誤をしてきました。定番のイラストレーター、パワーポイント、caccoなどのwebアプリ。
イラストレーターは、使いなれていますし、自由に使える反面、UIパーツから自作しなければならないので、手間がかかります。cacooは、そもそも使い慣れていないし…と、塩原的にはどれもしっくりこなかった訳です。

そんな中で見つけたのがUXPin

UXPinは、有料のワイヤーフレーム制作アプリです。予めUIパーツが定義されていて、ドラッグ&ドロップで配置していくだけ。非常に簡単に、ワイヤーフレームを作成することができます。

UXPin

言葉で説明するよりも、実際のデモを見てもらったほうが早いと思うのでこちらをどうぞ。

だいたい13分くらいでトップページと下層ページのワイヤーフレームができてしまいました!
(内容は超適当ですけどね・・・)

一つのプロジェクトで、複数ページのワイヤーフレームを作ることができ、それらのページが一つのサイトして、プレビューできます。
配置したオブジェクトには、クリックイベントが付与できるので、ワイヤーフレーム上で、実際の動きを確認することができます。

サンプル

ブレイクポイントも設定できるので、レスポンシブ案件の場合でも、動くデモとして確認ができます。

塩原的なUXPinの3つの使い方

1.デザイナーさんへのデザイン指示用

従来のワイヤーフレームの使用用途です。原寸大のフレームが動き付きで提供できるので、デザイナーさんもわかりやすいんじゃないかと思っています。
ウェブベースでのデモもできますし、当然PDFなどでも出力できますので、印刷して細かな指示を書いたりも簡単にできます。

2.クライアントとの情報共有用

ドキュメントベースで原稿を提供してもらっても、お客さんは実際にページにどう反映されるか想像しにくいものです。というか、できないと思っていた方がいいですよね。
従来ですと、デザインがFixして、コーディングを経て、原稿を落とし込んだものを確認という流れになるわけですが、そこまで手をかけて「NG」なんてバルス的なことを言われることもあります。(それをさせないのがディレクターの腕なんですが…)

そこで、こういったブラウザベースで簡単につくれるワイヤーフレームがあると、実際の原稿を実際のサイズ感で落としこんで確認してもらえるので、手戻りがあっても、時間的ロスが最小限に押さえられます。
制作側でも、ざっくりコンテンツを配置して、仕上がりをイメージしながら不足コンテンツを考えたりということも容易にできるのは大きなメリットです。

3.流し込み資料として

2の状態で、クライントとの承諾が取れていれば、後は作りこむだけです。
コーディング担当にいちいち紙ベースで指示書をつくらなくても、出来上がったデモ画面を渡せば、後は調整しながら、作りこんでいくだけです。

1つのワイヤーフレームを作り込むことで、サイトの設計、コンテンツの確認、作業指示ができてしまうわけです。

この使い方以外にも、Photoshopのデータを読み込む事ができますので、モックアップを作って、ボタンにリンクをはったり、サイトの動きをざっくり作って、動くデモを簡単に作ったりということもできるようです。

ディレクターさんは、しっかり企画をたてて、お客さんと社内のスタッフを巻き込んでウェブサイトを作っていくことが主な仕事だと思うんですが、それぞれに共通のアウトプットで行えるといのは、効率がいいと思います。
今回紹介したUXpinが最良の選択肢かどうかはわかりませんが、学習コストが低くて、パフォーマンスが高いツールであることは間違いないです。
塩原的に、もう手放せないツールになっています。

最近はやりのCSSプリプロセッサや静的ページジェネレーターの実務導入について考えてみた。

制作に関する話題です。
ここ数年(しかも割と早いスパンで)で、WEB制作のトレンドが大きく変わってきているように感じます。
例えば、SCSSといったCSSプリプロセッサ、Gruntなどのタスク実行ツール、Middlemanなどの静的ページジェネレーター。
今までは、CSS、JS、HTMLなどを直接記述していましたが、何らかのコンパイルツールを介する事で、効率よく制作、管理するというのが主流になっています。

実際僕自身も未熟ながらそういったツールの恩恵を得て、効率化を図っています。
実務の中でも、利用する機会が増えてきているのですが、その時のメリットとデメリット、注意すべき点について考えてみました。

メリット

・効率的かつ簡単にフロントエンドの実装ができる。特にCSS周りではSCSSなどの利用は必須です。
・ツール自体のエラーチェック機能があるので、致命的な記述ミスが減少する。

デメリット

・少なからずツールに依存してしまう部分がある。
・初期制作とメンテナンスを別人が担当する場合、利用するツールのすり合わせ、学習、ツールの管理などのコストが発生する。

簡単にまとめると上記のようなものかなと思っています。
つまりは、社内またはチーム内である程度の統一が必要であると。
当たり前のことです。便利だからという理由で勝手に使っても、その後を引き継ぐ人の事もケアされていないとかえって不便なツールになってしまったり、何人かの手を経て、初期制作者の元に戻ってきた時に当初想定していた運用フローからかけ離れたスパゲッティコードになっている。なんてことも考えられます。

結局は、運用フローもしっかり設計して、ルールを徹底しろってことになるんでしょうが、その時にきちんと指揮をとれる人間が必要だよねってことかなと思っています。

そんな訳で、コーディングというWEB制作の肝になる部分もきちんとケアできるディレクターでありたいなぁと思う今日このごろでございます。

あ、個人的に今更感がすごくありますが、Middlemanでの実装がとてもいい感じだったりしてます。
静的ページジェネレーターというよりは、SCSSのコンパイルツール的に使っています・・・
それなら、Gruntを覚えてそっちで対応しろよって突っ込まれそうですが。

scssとかのコンパイルにはkoalaがいい感じな件

最近はめっきり、scssを使ってcssを書く事が増えています。
特に、css spriteなんかは、compassの機能で画像まで吐き出してもらうようになって、かなり効率が良くなっています。
って使っていると言ってもそれくらいなんですが、それでもこういったメタ言語をつかうときコンパイルという処理が必要なことには変わりありません。

僕みたいなライトユーザーにとっては、「無料or低価格で、最低限の処理を楽にできる」というのが必須条件になるわけであります。

勉強を始めた当初は、scoutを使っていましたが、案件ごとに設定をするのがめんどうで・・・
いや、シンプルで使いやすかったんですけどね。

そこに登場したのがkoala
windows、macでも使えて、設定も超楽チン。
アプリを立ち上げて、プロジェクトのフォルダをドラック&ドロップするだけ。
koala02

フォルダ構成を自動で判別して、設定してくれます。
koala03

直感的というか、プロジェクトをセットするだけであとは何もしなくていいくらいです。この使ってる感ゼロの感じ素敵です。
compassにも対応してますし、僕は使っていませんが、CoffeeScriptにも対応しています。
立ち上げておけば、自動でコンパイルもしてくれるし、ファイル毎に書き出しの形式を設定できたり、エラーがあればアラートしてくれます。

Sublime Text2でもできますが、しばらくはこれを使いそうです。

それしても、web系のツールって、動物をモチーフにしたものが多いっすね。

TinyPNGはパンダだし、
SpriteCowはうしだし、
Koalaはコアラだし。

次はペライチサイト簡単作成ツールで、KIRINとかでるとか、でないとか。

web制作現場の悩みの種。破綻しにくいCSSの設計について考えてみた

最近、色々なところでCSSの設計に関する記事を読む機会が増えています。
はやり?このネタに関してはすごく切実な問題で、どうにかしないといけない常々感じていたのでちょうどいい機会なので、すこし考えてみようと思います。

経験的に行なっている事を中心に書きますが、これから導入しようと思うことも合わせて紹介します。参照元も掲載しますのでご了承ください。

まず前提としてジブンB型なのであまりガチガチなルールは、いやです。そんなの決められても困ります。「その辺はニュアンス」って言葉大好きです。(松本の方言でいうところの「なから」ってやつ)なので、ルールといっても方向性的な感じなゆるゆるなものだと思ってください。

矛盾しますが、ルールがあると効率がいいのは事実です。
基本的なことは、ルール化してルーチン的に処理できるのが理想ですよね。

セレクター名って決めるの難しい

CSSを書く上で、けっこうウェイトが大きいのがセレクターの命名ではないかと思います。
最近はなれてきたので、あまり考えずにホイホイと書いていますが、コーディングを始めたころは苦労したのを覚えています。
効率的な管理という面でも、わかりやすいセレクタ名をつけるというのは必須だと思います。
他人でも理解できる=10ヶ月後の自分でも理解できるということですね。
・・・自分で書いてて耳が痛い

そんな訳で、前置きが長くなりましたが、まずありがちなセレクタ名を分類してみます。

フレームとしてのセレクター

例)header main sub footer
レイアウトする上で、基盤となる枠組をつくるためのセレクターです。
主にIDで示される。

少し汎用的な固まりを示すセレクター

例)section item block box
文章のブロックや画像群など、ブロックごとに使い回すようなセレクター。

固有名詞的につかうCSSセレクター

例)hogehogeBnr
CSSスプライトなどを使う時に「このバナー」を特定するためのセレクターです。

ワークフレームとして使うCSSセレクター

例)clearfix mB10
善し悪しは別として、特定のプロパティをセットにしたセレクター。
clearfixとか

jsなどのトリガーとして使うCSSセレクター

特に説明は不要ですね。

ざっと思いつく限りですとこんな感じだと思います。

どうやったら効率よくセレクタ名を決める事ができるか?

ここでルール付けが必要になってきます。
上記の分類を参考に、フレームや汎用的なブロック、ワークフレームはルール化ができますね。

フレーム containaer(コンテナブロック),header(ヘッダー),
main(メインカラム),sub(サブカラム)
汎用的な固まり section,item,block,box
leftCol(左側のブロック)rightCol(右側のブロック)

※ワークフレームとしてのセレクタは少し意味合いが違うので省略します。

mod組みという考え方

codegridを読んでいて知ったのですが、高津戸さんが提唱するCSSの書き方なのですが、CSSを設計するときにモジュール(部品)に分けて書いていくという考え方です。
詳しくはcodegridをご覧ください。

mod組でいいなと思ったのが、セレクタの命名が直感的になるんじゃないかということです。
先に紹介したフレームと汎用的なブロックを組み合わせると
main-section header-leftCol のような絞り込まれたセレクターができます。
こうすれば、大規模なサイトを作る時にセレクタの競合が起こる事がすくなくなります。

この考え方はsassを利用したCSSスプライトでも使えます。
sassでのCSSスプライトはスプライトしたい画像名に依存してCSSの記述を書いてくれるのですが、
無計画にファイル名を記述すると、アルファベット順にならんでしまうので書き出されたCSSはかなりカオスになってしまいます。
そこで、モジュール名(フレーム)を接頭詞にして画像のファイル名をつけると、フレーム毎にまとまって書き出されますので、管理しやすくなります。

ワークフレームとしてのCSS

これ最近導入して、かなり便利だと思っています。
どうゆうことかというと、よく使うようなスタイル群を予め定義しておいて、htmlコーディング時にそのクラスを指定するだけでスタイルを適用させるという事です。

例えば、下方向にマージンを10px取りたい場合

<ul class="hoge">
 <li>ほげほげ</li>
</ul>
ul.hoge {
 margin-bottom:10px;
}

と書けばいいのですが、いちいちCSSを書くのはめんどくさい!ので
事前に

.mB10 {
 margin-bottom:10px;
}

と定義しておいて、htmlをコーディングする時に

<ul class="hoge mB10">
 <li>ほげほげ</li>
</ul>

と下方向にマージンを10pxとるクラスを定義するだけでよくなります。予め良く使うスタイルが定義してあれば、いちいちCSSを記述しなくてもすみますので、コーディングのスピードを上げる事ができます。
※あまり定義しすぎると、不要な記述が多くなったり、管理しきれなくなるので、最低限にした方がいいと思います。

命名ルール

少し余談っぽいですが、命名ルールもある程度統一しておいた方がいいかと思います。
たとえば、単語をつなぐ時にキャメルケースにするのか、「-」なのか「_」なのかとか。
※キャメルケースは単語をつなぐ時に後につづく単語の頭文字を大文字にする記述法です。
hogeItem みたいな感じ。

先述のmod組でいうと、確実に2つ以上の単語がつらなりますので、ルール化しておかないと却って分かりにくくなってしまいます。
個人的にはmod組の時は「-」でつないで、それ以外はキャメルケースというルールでやっています。

まとめ

セレクタ周りにしぼってまとめてみましたが、CSSは簡単なようですごく奥が深いと思いますので、他にも改善すべき箇所はたくさんあります。

ウチの環境はわりと小規模なので、コーディングを複数人で行なう事はあまりありませんが、メンテナンスも考えると一人で完結する事はまずありませんし、CSSのコーディングなんてサイト公開したら忘れてしまうものですので・・・

今回考えたルールがどこまで正しいかわかりませんが、余計な事を考えずに効率よく綺麗にかけるように、仕組みを考えていければと思っています。

静的なページ作成にはmiddlemanがいいかもしれない

mid

先日ruby製の静的ページジェネレータjegyllのご紹介をしましたが、静的なページの作成だったらmiddlemanの方がいいよというご指摘をいただき、試してみましたので、ご紹介します。

>middleman

middlemanもrubyで出来ている静的ページジェネレータです。
jegyllとの大きな違いは、システムに依存せずに、静的ページを生成してくれることだと思うのですが(違っていたらご指摘ください)
jegyllの場合、静的なページを作ることはできますが、公開する場合、サーバーにもjegyllがインストールされていないとだめだったような感じです。(すみません、詳しく調べていません)
なので、公開先としてはgithub pagesとか特殊な環境に限定されてしまうようです。

・・・歯切れが悪い説明だな。こりゃ

その点milldemanだと、build(いわゆるコンパイルです)すると、完全な形で静的なhtmlを生成してくれるので、そのままFTPとかでアップすればOKということですね。

僕がmiddlemanがいいなと思ったわけ

htmlをパーツに分けてコンポーネント化できる。

わざと難しく書きました。
つまりは、headerとかsidebarとか全ページ共通の部分を一つの塊として管理できるということです。

CMSでは、おなじみの処理ですね。

これができると、かなり便利です。個人的な話であれですが、このコンポーネント化をしたいがために、わざわざCMSでサイト構築をしていたりします。
これができれば、ドリでサイト定義して全ページ置換で修正なんて手間も省けるようになります。

テーマを複数作れる。

コンポーネント化に近いかもしれませんが、テーマファイルも自由に作成できます。
例えば、商品ページ用のテンプレート、店舗紹介用のテンプレートみたいな形で必要なテーマを用意しておけば、
流し込み作業も楽になります。

この2つにつきますね。
まだ実務で使っていませんが、使うのが楽しみです。

導入方法

僕が紹介するまでもありませんが、備忘録としてmiddlemanの導入方法をまとめておきます。

rubyはインストール済みという前提です。

middlemanのインストール
(sudo)gem install middleman

ダダダだ-っと文字が流れてきてエラーにならなければこれでOKです。

middlemanのプロジェクト作成

これもコマンドラインでの作業です。
適当なディレクトリに移動して

middleman init [プロジェクト名]

これでmiddlemanのプロジェクトを生成してくれます。
(macの場合システムのパスワードを聞かれます)

このプロジェクト作成時にオプション設定をすることができます。
詳しくはヘルプを見てもらうといいかと思います。

middleman init --help
テンプレート

middlemanにはいくつかのテンプレートが用意されています。default/html5/mobileなど
これらを利用する場合は

middleman init [プロジェクト名] --template=html5

のように指定します。

ちなみに、理由は分かりませんが、僕の環境だとdefaultでプロジェクトを生成するとbuildしたhtmlからcssやjsへのパスがうまく通っていないです。
他のテンプレートなら問題ないのですが…
詳しく検証していないのですが、もしかしたらテンプレートはhtml5とかのほうがいいかもしれません。

css/js/imagesディレクトリの名称変更
--css-dir= 

でcssディレクトリの名称を変更できます。
普段使っているディレクトリ名があれば、ここで設定変更するといいです。

プロジェクトが生成されたら、ローカル環境でテストしてみます。

コマンドラインでプロジェクトのディレクトリに移動して

middleman

これでローカルサーバーが起動して、サイトが閲覧できるようになります。

ブラウザでlocalhost:4567にアクセスするとサイトが見れるはずです。

ローカルサーバーの停止はctrl+Cです。

サイトのbuild(コンパイル)

同じくコマンドラインで

middleman build

これで、サイトを生成してくれます。
プロジェクトディレクトリの中にbuildディレクトリができているはずです。
この中のhtmlファイルを開くと、サイトが閲覧できます。

こんな感じで、middlemanでサイトが生成できました。

DEMO(かなり地味なデモですね)

次は、以前作ったモバイル用CSSワークフレームを使って、簡単なモバイルサイトを作ってみたいと思います。(公開日未定です…)

静的HTMLジェネレータ jekyllを考えるの巻

Jekyllというrubyの静的HTML生成ツールがあります。
実際に実務としては使っていませんが、割りと面白いツールですので勉強がてら紹介してみます。

インストールなどについては、詳しく説明しているブログが多数ありますので、ここでは割愛します。

Jekyllについて詳しく説明しているサイト
CodeGrid 有料ですがかなり詳しく紹介してあります。
ゆっくりと…【WordPressよりjekyllで本格的ブログを作りたくなる、かもしれないまとめ】
kaoriya 【Windowsでjekyllを使えるようにするよ】

ここでは、実際のweb制作の現場でどう使えるかを考えてみたいと思います。

Jekyllとは?

静的なHTMLを書き出してくるツールです。
と書くとすごく分かりにくいですね。
素のHTMLと違って、headerなどのパーツをインクルードできたり、ブログ的なアーカイブページができたり、テーマファイルの共有ができたりします。
データベースが不要ですので、ローカルで開発環境を整えるだけで利用可能です。

Jekyllはあくまでジェネレーターなので、自由にデザインを適用することができます。(逆をいうと、素の状態からのスタートになります)
※bootstrapを組み込んだJekyllワークフレームもあります。

ちなみに、jekyll-bootstrapはgit経由で簡単に導入できます。
(windows環境ではgitの設定など少し手間です。その辺の話題はまた後日書きます。)

git clone http://github.com/plusjade/jekyll-bootstrap.git インストールしたいディレクトリ

Jekyllでのサイト作成時のワークフロー

ざっくりと書くと
Jekyllの起動(コマンド)

ベースとなるファイルの作成、編集(テキストエディタ)

サーバー(ローカル環境)の監視&HTMLの生成(コマンド)

となります。

そう、黒い画面必須です。
残念ながら、これで、ハードル3割増し(当社比)

といっても、コマンド自体はデータのあるディレクトリに移動して

jekyll build

Webサイトの生成を行います。

jekyll build --watch

ファイルの変更を監視して、変更のあるたびにWebサイトの生成を行います。

jekyll serve

ローカルサーバを立ち上げてWebサイトのプレビューを行うことができます。URLはデフォルトでhttp://localhost:4000となります。

jekyll serve --watch

ローカルサーバを立ち上げつつ、ファイルの変更も監視してそのたびにWebサイトの生成を行います。

くらいですから、それほど大変なことではありません。

上記のワークフローも実際には、ある程度自動化できそうですが、肝心なファイルの作成、編集はテキストエディタで行なわなければなりませんし、htmlの生成もコマンドを叩く必要があります。

実際のweb製作現場では、どうかな?

前置きが長くなりましたが、実際の制作現場ではどうなのかというところを考えてみます。
ざっくりまとめると

使えそうな案件
・大前提としてCMSが導入できない案件
・ニュースリリースなどの定期更新が頻繁にある
・サイト構成が似通っていて、モジュール化できそうなデザイン

逆に導入しない方がいい案件
・更新は原則クライアントが行なう。
 →HTMLの生成にはコマンドを叩く必要がありますので
・windows環境
 →設定できますが、結構めんどくさいと思いました。

作業的には基本、テキストエディタで行ないますので、ドリームウィーバーなどのオーサリングツールを利用しているような場合も向きませんね。逆に、普段からCMSでサイト制作をしているような場合は、導入しやすいのではないかと思います。

モジュールのインクルードはかなり自由にできますので、事前にきちんと設計してサイトを作らないとカオス化必須です。

ただ、その辺の問題をクリアでき、作業フローをきちんとルール化できれば、コーダー/プログラマが設計、コーディングし流し込みをそれ以外の人に振るみないな分業化も可能になりそうだなと感じています。
かなりプログラマさんよりなツールなので、簡単に導入できる訳ではないかと思いますが、うまく使えれば作業効率が軽減できそうですね。

実際に使ってみて思ったのが、ノンプログラマにはすこしハードルが高いかもしれないということです。
インストールまではいいですが、サイト/ブログの作成、コンテンツの流し込み、公開に至るまでコマンドを叩く機会が多いです。

次回は実際につまづいてしまった部分を紹介したいと思います。

超シンプルなスマホサイトをテンプレート作ってみた

Advent Calendar in 信州松本(だけじゃなくてもいいよ)最終日です。まずは、今日までこの企画にご賛同いただき、参加&応援頂いた皆さん、本当にありがとうございました。ほんと、ぼぞっとつぶやいたツイートがきっかけで、これだけたくさんの方を巻き込んで、ここまでできた事、本当に嬉しく思っています。運営や広報的にイマイチな部分があって、後悔している部分も多いのですが、参加された皆さんの自主的なフォローにすごく助けてもらえました。
本当にありがとうございました。来年は、こうゆうオンラインの企画だけではなく、リアルな場にもつなげていければと思っていますので、今後ともどうぞよろしくお願いします。

さて、最終日ということで、どんなネタにしようか迷っていたのですが、超簡単なモバイルサイトテンプレートを公開しようと思います。
先日、クライアントワークで、簡単なモバイルサイトを構築したのですが、既存のモバイルワークフレームは使わずに、スクラッチから作ったんです。既存のワークフレームを使わなかった理由として、動的に情報を流し込むのが少し手間だったり(DOMの操作の関係とか)、cssの構造が複雑すぎて、デザインしにくかったりと、高機能がゆえの弊害があげられます。
余計なページトランジッションとか付けずに、対応サイズもスマホに限定すれば、cssだけでもある程度の事はできます。
コンセプトとしては、モバイルアプリ開発のモックアップ用くらいの完成度で小難しいルールなしにcssだけで実現させるです。

実際のデモはこちら。

カラーバリエーションは、随時増やしていきたいと思います。

使い方は、基本のcssを読み込んで、html側で使いたい機能のクラスを呼ぶだけです。
※ボタンをタッチした時のアクティブ表現をしたい場合は、java scriptで判定しなければなりません。

スマホのサイズのみを前提に考えていますので、複雑なレイアウトは組んでありません。いわゆるレスポンシブというやつですか。
あくまで、スマホのモックアップを作るためのフレームだと思ってもらえればいいかと思います。

使い方

こちらからデータをダウンロード(zip)して、
normalize.cssとsimpleMobileTemplate.cssを読み込みます。

後は、下記のルールに従って記述してください。

コンテンツブロック

<div class="itemBlock">

</div>

divでもsectionでもarticleなんでもいいですが、角丸の背景白のブロックを生成するには、.itemBlockとしてください。

タイトル

基本的にコンテンツブロック内で利用することを前提にしています。

<h3 class="title thin">タイトル</h3>

このように、.titleと.thin or .darkと指定してください。
ちなみ、.titleでタイトル用のスタイルのベースを定義して、thin or darkで色の濃さを定義してあります。

<h4 class="subTitle"><span>ナビゲーション</span></h4>
<nav class="itemBlock">
 <h2 class="title thin">MENU</h2>
 <ul id="gnavi">
   <li><a href="#"><span class="icon allowIcn"></span>メニュー</a></li>
   <li><a href="#"><span class="icon allowIcn"></span>メニュー</a></li>
   <li><a href="#"><span class="icon allowIcn"></span>メニュー</a></li>
   <li><a href="#"><span class="icon allowIcn"></span>メニュー</a></li>
 </ul> 
</nav>

こんな感じで定義してください。

ボタンセット(くっついている版)

<article class="btnSet">
 <div class="btnSetTop contactBtn btn"><a href=""><span class="icon mailIcn_w"></span>メールでのお問い合わせ</a></div>
 <div class="btnSetMidLeft btn"><a href=""><span class="icon gearIcn_w"></span>ボタン</a></div>
 <div class="btnSetMidRight btn"><a href=""><span class="icon calenderIcn_w"></span>ボタン</a></div>
 <div class="btnSetLeft btn"><a href=""><span class="icon telIcn_w"></span>ボタン</a></div>
 <div class="btnSetRight btn"><a href=""><span class="icon checkIcn_w"></span>ボタン</a></div>
</article>

こんな感じです。

<h4 class="subTitle"><span>ボタンセット(分離版)</span></h4>
<ul class="btnSet">
 <li class="btnSepa btnSepaLeft btn"><a href="index.html"><span class="icon homeIcn"></span>トップページ</a></li>
 <li class="btnSepa btnSepaRight btn"><a href="#"><span class="icon pcIcn"></span>PCサイトを見る</a></li>
</ul>

こんな感じです。

と、かなり適当な説明ですが、基本コピペでテキストや画像だけ差し替えてもらえればいいようにしてあります。
もっとブラッシュアップしていきますが、使う機会があればご自由にお使いください。

jQueryで背景画像がクロスフェードするやつ

背景画像がクロスフェードするの

Advent Calendar in 信州松本(だけじゃなくてもいいよ)20日目、担当4_1です。
昨日のToro_Unitさんの投稿、僕は、普段独自のCMSを使っているので、wordpressの可能性を感じて大変参考になりました。このブログもwordpressでつくってあるんですけどね。「ブログ」の域をを越えて、CMSとしてもwordpress使ってみたくなりました。

さて、今日のネタは、少しかぶってしまいますが、jqueryで背景画像をクロスフェードさせるのです。よくわからない説明ですが、こんな感じです。

DEMO

作ったと言ってもクロスフェードの部分はWeb Designing: 2012年12月号に掲載されていたサンプルを参考にしています。
今回のデモですと、画像ではなく背景画像を指定したdivをクロスフェードさせています。

背景画像なので当然、widthとheightを指定しないと画像は表示されません。
heightは画像の高さを指定すればいいです。
ではwidthは?
画像のサイズを指定してしまうと、実際のコンテンツサイズよりも大きくなってしまう可能性があります。(コンテンツエリアよりも広いスペースでのクロスフェードを想定してます)
その場合、当然横スクロールが表示されてしまいます。

解決策としてjqueryでこのブロックのwidthの値を制御するようにしました。
今表示されているウインドウの幅を取得してその値を代入します。
それだけでは、ウインドウの幅を変更された時におかしな事になってしまいますので、
$(window).resizedeでウインドウ幅の変化を調べてその都度最新のウインドウ幅を代入するようにしてあります。

こんな感じのコードです。


var windowResised = false;
$(window).resize(function() {
if (windowResised !== false) {
clearTimeout(windowResised);
}
windowResised = setTimeout(function() {
pageWidth = $(window).width();
$(‘#bgFade div’).css(‘width’,pageWidth);

if($.browser.msie && $.browser.version < 8){ var fixforIE ='-'+$(window).width()/2;  $('#bgFade div').css('margin-left',fixforIE); } }, 200); }); [/javascript] また、IE7以前のブラウザですと、背景が実際のウィンドウ幅の半分ずれて表示されるというバグがありましたので、簡単な判定をして回避しています。 [javascript] if($.browser.msie && $.browser.version < 8){ var fixforIE ='-'+$(window).width()/2;  $('#bgFade div').css('margin-left',fixforIE); } [/javascript] クロスフェードする要素でpostion:absoluteしているので、うまくレイアウトできない場合があります。 実際にページに組み込む場合は、少しテクニックが必要ですが、ダイナミックな演出を使いたい場合など、利用できるかもしれませんね。

一応使い方を

html

<!-- クロスフェードするブロックは#bgFade内に記述します。 -->
<div id="bgFade">
 <div class="slide01"></div>
 <div class="slide02"></div>
 <div class="slide03"></div>
 <div class="slide04"></div>
</div>

<!-- ここから下が実際のコンテンツになります。 -->
<div id="container">
 <div class="content">
  <p>ここにコンテンツを記述します。</p>
  <p>ここにコンテンツを記述します。</p>
  <p>ここにコンテンツを記述します。</p>
  <p>ここにコンテンツを記述します。</p>
  <p>ここにコンテンツを記述します。</p>
  <p>ここにコンテンツを記述します。</p>
  <p>ここにコンテンツを記述します。</p>
  <p>ここにコンテンツを記述します。</p>
 </div>
</div>

css

/* クロスフェードする背景のdivを重ねておきます */
#bgFade div {
  position: absolute;
}
/* クロスフェードする背景の定義
  widthはjqueryで動的に入れるので定義しません
*/
.slide01 {
 background: url(../images/01.jpg) no-repeat center top;
 height: 510px;
}
.slide02 {
 background: url(../images/02.jpg) no-repeat center top;
 height: 510px;
}
.slide03 {
 background: url(../images/03.jpg) no-repeat center top;
 height: 510px;
}
.slide04 {
 background: url(../images/04.jpg) no-repeat center top;
 height: 510px;
}

あとは、jqueryとbgFade.jsを読み込めば完了です。
プラグイン化してませんので、設定は適当に変えてください。

Advent Calendar in 信州松本(だけじゃなくてもいいよ)残り5日です。見切り発車的にスタートしましたが、お陰様で全枠埋めてもらいました。あと少し、業務も忙しいと思いますが、頑張っていきましょう!
明日は、@Ken_54さんの同僚の方がデザイン系のネタを書いてくださる予定です。お楽しみに!

モバイルサイト製作について考察

Advent Calendar in 信州松本(だけじゃなくてもいいよ)15日目です。昨日のハラヒロシさんに引き続き、4_1が担当させて頂きます。

このブログでもモバイルモバイルって、色々言ってますが、実はあまり実務経験ありません。ほぼバージンですorz

そんな僕ですが、周りから入ってくる情報や、うちでのweb製作の流れ/方法、そしてメンテナンス性なども考えてこうすれば、割と効率的じゃないのかな?という考えはあります。
前日、クリエーターさんと飲む機会があって、酔った勢いでろくに経験もないのにのうのうと語ってしまいまして・・・自戒の念も込めて、今日は、まじめに少しまとめてみたいと思います。

前提として・・・
web製作はCMSで行なうものとします。
モバイルファーストではありません。
PCサイトありきで、モバイルでもある程度最適化してみたいなぁ程度です。

キーワードは、モジュール化とテンプレート化じゃないかと思っています。
※言葉の使い方が間違ってたらご指摘ください。

モジュール化

まず、モジュール化について、この考え方は、couldの長谷川泰久さんからの影響が大きいのですが、偶然にもうちで使っているCMSとの相性もよいので、注目している考え方です。(モバイル以外の部分でですが)

could:コンテンツを意識してWebデザインするとは

ページを構成する単位って、当然htmlになるのですが、もっと細かく見ていくと、(header+sidebar+footer)+コンテンツみたいな形で微分できます。
この前者の部分をいわるゆCMSでは、テンプレート化して使い回している訳ですが、コンテンツの部分も細かく見ていくと、画像と文章のブロックに分類できます。(デザインなどに寄りますので、一括りには言えませんが)

この画像と文章のブロック=モジュールを必要に応じて組み替えてページを構築していければいいのではないかという考え方です。それができれば、同じような情報の組み替えただけのページをいちいち複数作らなくても、情報だけ登録しておけば、自由に構築し直す事ができるようになります。

テンプレート化

これは、文字の通り、細かなブロックを必要に応じて組上げる時の設計図としてテンプレートを利用します。
細かな文章や画像というモジュールを必要に応じて組み合わせるための設計図ということでしょうか。

で、このテンプレートをサーバーサイドではなく、java scriptで行なってしまえば、いいんじゃないかと思っています。
jquery.template.jshandlebars.jsと言ったいわゆるjavascriptのテンプレートエンジンがいくつかあります。
これらを利用すると、サーバーサイドの言語を使わなくても、ページの再構成が可能になります。

例えばこんな感じ。

PCサイト風
モバイルサイト風

便宜上CMSを利用していませんが、どちらも同じjsonファイルを利用して表示しています。

{
  "entry": [
    {
      "title": "タイトル1",
      "content": "どっどど どどうど どどうど どどう 青いくるみも吹きとばせ すっぱいかりんも吹きとばせ どっどど どどうど どどうど どどう",
      "imgSrc": "images/img01.jpg",
      "id": "page01"
    },
    {
      "title": "タイトル2",
      "content": "谷川の岸に小さな学校がありました。教室はたった一つでしたが生徒は三年生がないだけで、あとは一年から六年までみんなありました。運動場もテニスコートのくらいでしたが、すぐうしろは栗の木のあるきれいな草の山でしたし、運動場のすみにはごぼごぼつめたい水を噴く岩穴もあったのです。",
      "imgSrc": "images/img02.jpg",
      "id": "page02"
    }
  ]
}

今回は詳しいソースの説明は割愛しますが、jsonを読みこんだりする関係で、javascriptでゴリゴリな感じです。それ以外の部分は、ごくごくシンプルですし、そもそもPCページとモバイルページのファイルが違うので、レイアウトも含め自由に変える事ができます。

サーバーサイドでは、最低限のjsonだけ書き出せるようにしておけば、色んな形で使い回しが可能なのかなと。

この使い回しというのも大切なキーワードで、いわゆるワンソースで構築するとどうしてもコードが煩雑になってしまいますし、デザインの制約も少なからず発生してしまいます。
その点、この方法だと、PCとモバイルは別物でデータだけ共有させていますので、それほど、煩雑なコードにはならないですし、デザインもある程度自由です。

まとめると、ページをhtml単位で考えるのではなく、もっと細かいデータの固まりとして捉えて情報を設計すると、今まで実現が難しかったような来よが自由にできるようになります。それは、スマホ対応だけではなく、サイト全体でも言える事です。ちなみに、某緑のチームのサイトもこの考え方を採用して、随所で情報の流用をして、管理を簡略化しています。(そこでは、javascriptのテンプレート化はしてませんけどね)

レスポンシブやモバイルファーストでのサイト設計を否定するものでもありませんし、この方法の場合も、利用できない状況もありますので、万能ではありませんが、一つの手法として、よいかなと考えています。実際に試していない部分もあるので、頭でっかちな記事になってしまいましたが、来年はこの辺をもう少し掘り下げていきたいと思っています。

Advent Calendar in 信州松本(だけじゃなくてもいいよ)そろそろ終盤に向かっております。参加して頂いている皆さんのおかげで、順調に進んでいます。あと数日まだ空きがありますので、参加しようか悩んでいる方、ぜひぜひ、ご参加ください。よろしくお願いします!

これまで扱った事があるECサービスまとめ

Advent Calendar in 信州松本(だけじゃなくてもいいよ)10日目です。昨日のthinkAmiさんの「GoogleAppEngineとGoogleAppsScriptでアルクマを追いかける」web製作を中心に行なっている僕からすると、ふだん利用しているgoogle系サービスやhtml/js/cssでここまでできるんだ!とかなり目から鱗な記事でした。web屋も難しがらずに新しい事に挑戦していかなければと感じました。

さて、ここからが本題です。
web製作を行なっていく中でついてまわるのが、ECサイトです。冒頭のお話ではありませが、システム系にあまり強くないweb制作者にとっては、けっこう頭が痛い部分でありますが、ニーズもある事です。ちまたには、無数のECサイト作成サービスがありますが、今日は、参考までに今まで扱った事があるサービスをまとめてみます。

EC-CUBE

http://www.ec-cube.net/
言わずとしてた、国産オープンソースのECシステムです。
かなり初期の段階のものから利用していました。一番の魅力は、無料で高性能な機能を利用できる事でしょう。また、phpが分かる方であれば、カスタマイズもできますので、クライアントの細かいニーズに対応もできます。

実際に利用した感想としては、デザインのカスタマイズが大変!(最新バージョンではわかりませんが)
昔、ブログに書いた事があるのですが、テーマファイルのディレクトリ構成が複雑ですので、理解できるまでに少し時間がかかりました。

EC-CUBEカスタマイズ手順

商品画像のアップロードは、csvでできるのですが、画像は別扱いになりますので、商品数が多い場合は、結構大変です。

管理画面のUIは、かなりきれいに作り込まれていますので、クライアントサイドの更新は非常に楽だと思います。

エクスカート

http://www.xcart.jp/
いわゆるASPタイプのカートシステムです。(正確には、レンタルサーバーのプランもありますが)
このサービスの一番のメリットは、送料計算です。送料の重量加算ができますので、例えば、商品Aは、送料500円だけど、商品Bと一緒に購入すると、梱包の関係で700円にしなければならないというような事にも対応できます。

管理画面のUIも直感的に作られていますので、エクスカートのみでサイトを構築すれば、クライアントからの手離れもよいかと思います。

この手のサービスでよくあるのが、商品画面のカスタマイズが難しいという事だと思います。例えば、特別な商品だけランディングページを作成して云々のような場合。
当然このエクスカートも、レンタルサーバープランを利用して、エクスカートのみでサイトを構築する場合は、対応が難しいのですが、自サイト+エクスカートのASPプランで構築すれば、その辺の問題も解決できます。つまり、カートのみ外部(エクスカート)に出して、商品ページは自サイトで自由に構築する感じですね。
もちろん、手間も増えてしまいますので、安易に導入はできませんが・・・

Carrito(カリット)

http://www.carrito.jp/
「Google App Engine」で稼働する、ECプラグインシステムです。
ECプラグインというのは、的を得た表現だと思うのですが、先述のエクスカートの後半部分で述べたような、自サイト+カートシステムに近い考え方です。

カリットの決済画面は、非常にシンプル(というかカスタマイズできない)なので、商品だけ登録すれば、すぐに使えます。非常に簡単な画面なので、逆に別でページを用意しないと商品説明ができないレベルです。
逆にいれば、既存のページにちょっとだけカートを組み込みたいというような場合にリンクを貼るだけで、ECサイトにすることが可能なので、利用する機会も多いかと思います。

シンプル/安価がゆえに、細かいニーズには答えられない場合もありますが、導入コストも抑えられるので、気軽にECサイトを始めてみたい場合には、有効かと思います。

その他、最近ではStores.jpBASEといった、もはやweb屋はいらねんじゃね?的なサービスも増えてきました。どれがいい、悪いという議論ではなく、クライアントのニーズに合わせて、最適な提案ができるように引き出しを増やしておかないといけないなぁと感じる日々でございます。

以上、これまで扱った事があるECサービス(一部)のまとめでした。(手抜きな記事でごめんなさい)