テンプレート

ページの中でヘッダーやフッダー、サイドナビ等、数ページに渡って共通のものを入れている場合、個々のページにソースをおくよりも、テンプレートとして作ったほうが便利な場合があります。

そこらへんでいくつかのアプローチがあって（私の関わった範囲で）

・Dreamweaverのテンプレート機能

・ＳＳＩ（サーバサイドインクルード）

・ＰＨＰ
（これもインクルードで読み込む形）

 

ってなものがあるのですが、それぞれ利点があるし、どれを使うかは環境などによっても異なるのですが、先日に感じたのは便利だと思ってたDreamweaverのテンプレートもけっこう大変だな、という事です。

 

テンプレート機能のいい所は、元を直せばそれを使っている前ページに適応されますし、階層が変わっても対応してくれます。

それでいいなーって思ってたのですが、先日に感じたのは

『サイトの規模が膨大になるとそれはそれで怖い』

という事です。

 

テンプレートを更新すれば、その都度それを利用しているページを全部更新して適応させなければなりません。それが膨大なページで、サーバにupするのが大変だったりするとちょっとイヤになります。

個々のページでテンプレートのさらなる修正をした部分とかが変わってしまっていないか心配になったり。

これがＳＳＩやＰＨＰで作れば、そのファイルを変えてUPするだけで、利用しているページはそのソースごと読み取るので更新の必要はありません。

ただし、ＳＳＩとＰＨＰはローカルではプレビューできないという問題もあります。

 

どれを使ってもそれぞれの利点・問題（というよりは心配？）があります。
どれを使うのが一番！なのかは言えません。少なくとも私は。

適材適所、それぞれの場面にあったものを選んで、有効に（もとい、心配を少しでも減らせるように）していきたいものです。

自分が心配性なのでｗ

 

 

 

 

ひと悶着？

作業は複数の人が関係して進むけれど、誰かの仕事や都合で遅れたり変更になったりとする事も当然あるわけで、そんな中で起こった些細な出来事。

悶着と言うほど大した事でもないのだけれど、こういう事も起こりうるんだなという教訓の意味を含めて記述。

 

キャンペーンのページを作り、各店舗のページからバナーにした画像からリンクを貼る作業が発生。

普段は各店舗共通の内容が殆どなんだけれど、今回は各店舗の間で多少の違いがある為にそれぞれ用のページを用意。

バナーの画像を置く時に、CMSを利用している時と普通にHTMLソースのみで置く場合があります。今回はCMSで置いてくれとディレクションに言われていました。

CMS等のシステムが絡む場合は、ちゃんとシステムエンジニア（以下SE）がその部分を担当しているので私とは別作業になります。

 

このタイミングでたまたまSEさんがお休みを取っていたために週末をはさみ、作業が数日遅れる。（その間にオーサリングを終わらせる）

 

そして週が明けてSEさんに頼んでしばらくすると、SEさんに呼ばれて
「これは〜だからCMSじゃなくて普通に置いたほうがいいと思う」
と、言われる。CMSの理由は私には詳しくわからないのでとりあえず普通に置いたほうがいいという事だけ理解する。

 

この時点でディレクションは夜まで外出の為、SEに言われたとおりに私のほうで普通に設置を進める。

 

夜にディレクションが帰社。SEさんはすでに退社。
なにやらディレクションさんがその作業にご立腹のご様子。

呼ばれて、なんでCMSにしないの？なんでできないの？できるハズなんだけど。
自分は「〜」な理由でCMSにしたいんだけど。

と、まくしたてられるものの、このサイトのCMSの細部など私には当然わかるわけもなく、またSEさんの話も全部理解できているわけではないので詳しくはわかりませんとしか言えず。

「翌日にSEが来たらもう一度話し合って」
と、言われてその日は終わり。

 

翌日、SEさんに話をして、ＳＥさんからディレクションに説明をしてもらう。
「あぁ、そういう理由だったのか、ならばしょうがないね、ＯＫ」
と、あっさりと現状でかまわないという状態に落ち着いたご様子。

 

え？あんな風に言われた私の立場は・・・？

 

確かに理由を全部きちんと把握してなかったのは私の反省点ですけどね。
普通に置いてとSEさんに言われたときにディレクションに確認を取りたいとも思ったけれど、外出中でただでさえ作業が遅れてたので先に進めてしまったという事情も。

 

共同作業と言っても、同じ作業というくくりだけではなく、それぞれの分担作業とその連携という面も大切だとあらためて感じるひと騒動、でした。

更新作業

サイトを製作する中では新規の案件であったりリニューアルであったり、または作ったサイトの更新管理であったりと色々な形があるわけですが、更新を管理するとなるとやはり忙しくなるのが基本的に月末と月初めです。（週間で更新するような場合はまた別ですが）

更新の規模もテキストの修正、変更からデザインの変更、あるいは新規キャンペーンの作成と幅広くあります。更新だから簡単そうだと侮っては痛い目にあいます。

そんな中で、最近はCMS（コンテンツマネージメントシステム）を導入するサイトも増えてきているので、作業の分担、効率が以前よりも良くなってきていると思います。

CMSでは簡単なインターフェイスからテキストや画像などの変更をクライアント側で行なえるように作られています。
なので新しいニュースや変更のお知らせなどは、製作会社を通さない分早いしスムーズに行なえるという利点があります。

製作会社側にとっても、デザインなどを含む作業に限定できるわけで、双方にとってプラスになっていると思います。
これからはどんどんこういった仕組みが増えていくのではないでしょうか。

 

そう、そして今まさに私は月末更新の真っ只中なわけです。毎月の後半になってくると定期的な更新プラス新規のキャンペーンなどがコンスタントに入り（月の半ばでも色々とありますが）そして日にちが決まっているから程よい（?）緊張感と共に作業をしています。

今日はそんなさなかのつぶやき。

 

ブラウザチェック

webサイトを作成する上ではかかせないのがブラウザチェック。

まぁ、テーブルレイアウトでspaｃer.gifを使いながら作っていればそんなに各ブラウザ間の誤差がでるわけでもないので割と安心なのですが、これからはやはりフルCSSのサイトが増えていくという事で、ブラウザチェックも大変になってきます。

大体において対称なるものが

 

IE5.0/5.5/6.0＋これからは7.0も

firefox

netscape4.0〜（ネットスケープを対象外にする事も）

mac版IE6.0

mac・Safari

という感じでしょうか。細かくすればOperaもありますが、そこまで細かく対象とする事もなかなか無いです。

特に重要なのは、やはりシェアの殆どを占めるIEです。

CSSに関してはバグが多いし、正直私も好きではないのですが、シェアがある以上はしょうがないですね。

しかもこれの面倒な所は、バージョンをひとつのパソコンにひとつしか入れられないという事で、複数のバージョンをチェックするにはそれだけの本体を用意していないといけないのがまたツライ所。
会社ではそういう事の為に共用パソコンが数台あり、チェック等の為に使っていたりします。

そんな中で、これは便利だなっと思ったソフトをひとつ紹介します。IEがそれぞれスタンドアローンで動くというものです。
（個人的に私は使用していますが、ウィルス・故障その他の責任を持てないのでもし使用するときは各自の自己責任においてお願いいたします。私もウィルスチェックはしていますが、会社では不用意にそういったソフトを入れない為に、自宅でしか使っていません）

http://browsers.evolt.org/?ie/32bit/standalone

これを使って驚いたのは、IEを立ち上げるとマイクロソフトのトップページに飛ぶわけですが、IEの5.5を立ち上げてみたら、見事にCSSのレイアウトが崩れていましたｗ

マイクロソフトさんは自社ですでに対象外にしてるのですか？？？

タブブラウザ

私が家と職場で使っているブラウザはSleipnirというタブブラウザを使っています。

FirefoxやIEの7でもタブがありますが、私は以前から使っているという理由とか、色々あってこれを使いつづけています。

http://www.fenrir.co.jp/sleipnir2/

ブラウザはそれぞれ慣れや相性があると思うので、これが一番！というのはどれにも言えないと思いますが、私はコレがお気に入りで、周りにもよく勧めています。

主な特徴は

・国産ブラウザ
・タブなので、複数のサイトを開いていても軽い。
・IEのエンジンを使っているので動作はIEとほぼ同じ
・カスタマイズが豊富

特に、カスタマイズにおいて便利な機能をたくさん使っています。マウスの動作を独自の設定で
アクション設定できるので、私の場合は「右ダブルクリックでそのウィンドウを閉じる」とか。「真中のすくrーるボタンを押すとひとつ戻る」とかをよく使っています。

私はタブをいつもたくさんタブを開いているので、時々周りには「開きすぎじゃない？」と突っ込まれたりもしていますｗ

そして、個人的な楽しみ方だけではなく、webデザインを学ぶ上でも便利だと思う理由のひとつがSleipierに用意されているプラグイン、Hawkeye です。

http://extensions.tabbrowser.jp/plugins/detail.php?plugin=Hawkeye

divやtableの構造をビジュアルで構造解析したり、imageのサイズ表示、CSSの確認やユーザビリティのチェックまで、とにかく豊富に確認する事が出来ます。

自分のサイトを確認するのももちろんですが、気に入ったサイト、お手本にしたいサイトなどをこれで確認してその技術を構造解析していくのはとてもいい勉強になると思います。

 

…まぁ、ブラウザチェックの対象にはなりませんけれどね。
（でも、表示はIEのエンジンなので、基本的にIEと同じように見えています。）

SSI サーバサイドインクルード

最近、また更新やページ作成等を行なうサイトを一つ引き継ぎました。

サイトが違えば構造も違う。

また全体を把握するのに時間をかけていかないといけません。それが店舗数などがけっこうあり、それぞれの店舗毎にページを持ってたりするのでまた大変。

それと共に今度のサイトの特徴はSSIが含まれているという事です。

「サーバサイドインクルード」の略で、phpと同じように、一つのファイルを別で作っておき、それを各ページに

<!--#include virtual="****.html" -->

のように記述しおけば、その部分が読み込まれて表示されるという便利な機能です。
（記述の仕方はサーバなどの種類によっていくつか異なります）

ヘッダーやフッダーに使うこともありますし、たとえば全店舗に共通した一文を載せたい時などに普通の文章の中に埋め込むというふうにもつかえます。応用はかなりできます。

難点は先日に書いたルートパスと同じように、これもローカルではプレビューできないので、サーバにあげてからでないと確認できません。

便利なような、不便なような。
でも使い方をマスターすればかなり効率があがります。

しっかりと覚えておきたいテクニックのひとつです。

ルートパス

webを製作している中で、リンク先へのパスの記述によく使われるのが『相対パス』、それに『絶対パス』があり、この二つがメインだと思うのですが、さらにもうひとつあるのが『ルートパス』です。

あんまり目にしないものなので私もすっかりわからなくて悩んでしまいました。

相対パスと似ていて、表記上の違いは

相対パス『../hoge/index.html』

ルートパス『/hoge/index.html』

なんです。ぱっと見たらわからないと思いませんか？

ルートパスの考え方は絶対パスと基本的に同じで、http://以下を/で表記するというものなのですが、これに注意しなくてはいけないのは、ローカルでのプレビュー表示では見れないということです。（絶対パスも見れません）

製作している段階でプレビューしても見れないので、サーバに上げないと実際につながっているのかどうかが確認できません。

…じゃあなんでそんなめんどいものを使う必要があるのか？

それはそれぞれに利点があるので一概には言えませんが、私においては引き継いだサイトにおいてルートパスが使われていたのでそれに倣ったわけです。

あ、でも重要なポイントがあります！
相対パスは場所や階層が変わると繋がらなくなりますが、ルートからの記述にすると階層が変わっても表示されます。
なのでサイトの階層を頻繁にいじる可能性がある人は嬉しいと思います。

サイトを製作、管理していく上では一定の規則にのっとって作っていかないとバラバラなソースでは後々困ることがあります。泣けてくるほどに。すでに実感。

なので、できるだけベースとなるものを受け継いで作ることが大切です。

でも、そんなに使う頻度は高くないと個人的には思うんですけどね。

そんなわけで『ルートパス』という考えを頭に刻み込んだ一日でした。

PDFの表示倍率

webサイトを作成する中で、PDFを作る機会もけっこうあります。

クライアントのスケジュールや配布するパンフレット等をPDFとして用意するんですね。

PDFとしてそのままクライアントから受け取る事もありますし、データをこちらでPDFに作り直す事もあります。

 

そんな中で以外に気が付かない部分が表示の倍率。

 

たいてい、ユーザーのモニター環境や前回のアクロバットリーダーの終了時の設定をそのまま受け継ぐのですが、この最初の表示倍率を固定するって事は結構盲点でした。

どうするのかっていうとアクロバットで保存をする時に、文書のプロパティというところで【開き方】というタブがあり、その中に「倍率」という設定があります。

通常は「デフォルト」となっていて、これがそのユーザー環境に依存しているわけです。

これを任意の数値に変える（75%等）と、その大きさで開くようになります。

 

この設定、以前の私は知らなくてクライアントに大きく表示されて画像が荒いのが見えると言われても「100%できれいに見えるようになっていますので」としか言えませんでした（苦笑

共同制作

仕事でプロジェクトとして動けば、当然複数で作業を行なうことになるわけですが、やはり同じ仕事をしていても人は人。ファイルにもクセが顕れます。

テーブルレイアウトの区切り方、マージンのとり方、フォントのCSSのあて方etc・・・


一人でやるのも気楽でいいんですよ。小規模のリニューアルぐらいだったらそれぐらいしてますから。でも複数になると結構大変。

それこそ、前の日記で書いたjavascriptの問題もそうだし、画像を格納するフォルダも個別だったりまとめてたりとか。

自分のやりやすいようにするのが一番の効率だけど、複数の人が見ても理解できるようにしておく事も大切ですね。

特に【コメントアウト】

ヘッダー、本文、フッダーなどの区切りに書く人もいますが、ここからさらにパーツにわかれている部分にまで書いているとすごく助かります。

ネットで気に入ったサイトのソースを見るときも、おぉ、この人はやさしいなぁって感動したりｗ

あ、ソースを見るといえば文字コードの関係でソースに「美乳」とあるサイトが結構あるとか。Yahooは「京」でしたっけ？

気に入ったサイトのソースはすごく勉強になります。

ソースを見れば、人の手が途中で変わってるとかもなんとなく判ったりもします。
共同制作は円滑にできるように常に気を配りたいと思いながら、これから作業にはいります。

テーブルレイアウト

最近は[ web2.0]や[CSS]という言葉をwebサイトを製作する上でよく聞きます。

むしろ聞かないほうが少ないでしょう。それぐらい浸透していると言う事です。

では、現場はどうなっているのでしょうか…

 

テーブルレイアウトが主流です。

[フルCSS]も無くはないですが、少ないです。（テーブルレイアウトにおいてもフォントサイズや色の指定などはCSSを利用するので、区別する意味でフルCSSと言ったりします。）

まぁ、フルCSSが使われだしたのはまだまだ最近ですし、その前から作成しているサイト等は当然です。でも。今から作るサイトでもまだまだ多いんですよ、ホントに。

それには理由があるからなのですが、大まかに言うと

『作ったサイトをクライアント自身が更新する上での技術的な問題』

『製作にかけられる期間の問題』

があります。

 

サイト製作を依頼した後、クライアントが自身で更新などをするケースがあります。ファイルをまるまる渡す感じですね。

フルCSSは新しい技術であり、これを使いこなすのはけっこう大変です。テキストを変更するだけならまだ大丈夫ですが、レイアウトが絡むと色々と。

なので、わりと使いやすく、かつ昔の技術ではありますが、理解している人口も多いテーブルレイアウトが使われ事があります。

 

製作にかけられる問題ってのは、あまりいい話ではありませんが、フルCSSはやはりバグに対処する問題がテーブルレイアウトとは段違いなので、比べると多くの時間を必要とするのは仕方がないかと思います。（おまえが慣れていないせいだ！と言われるとその通り魔のですが）

もちろん、覚えたほうがいいです、フルCSS。重宝されます。

でも。テーブルレイアウトもまだまだ多いので、きちんと知っておいたほうがいいと思います。

フルCSSオンリーを勉強した知り合いが、派遣登録に行きスキルチェックを受けたときにテーブルレイアウトの更新をさせられて全然できなかったそうです。

そしてその派遣会社に言われた言葉が

「まだ現場ではテーブルレイアウトも多いので使えないと大変ですよ」

だったそうです。

これからwebデザインの世界に入ろうとする方へのアドバイス？でした。

 

クライアントの違い

製作するにあたって、もちろんクライアントからの依頼があるわけですが、会社や団体などのクライアントから受ける事もあるし、広告代理店などを通して受ける事もあるわけです。

ページを作ることにはかわりがないのですが、どんな部分が異なるかというと、

【直接】
○ページ製作・修正・相談等の依頼が直接来る。

【間接】
○代理店を通して修正・指示などが来る。

というような事ですが、どちらもいい面、つらい面があって

直接の場合、納期や変更などの要望もこちらからも伝えやすく話し合いがスムーズ。だけど本当に細かいなぁって事の指示がちょくちょく来る。

代理店の場合は提案など代理店が主に考えて交渉してから話が来る。あるていどwebに理解のある代理店を通してると無理難題な相談などはこない。
製作などの確認がひと手間増えるのでちょっと時間がかかる。ひと手間ある分、それぞれの作業の納期がタイトになる事もある。

 

なんて感じだったりするのですが、webで仕事をしている他の人はどちらのほうが好きなのかなぁ。
自分はまだ駆け出しの身なので、どちらもただがんばっていくってだけなんですどね。

あ、代理店とかだと、この案件ではタッグを組んでいるけれど、別のコンペではライバルとなっていう事なんてのもあるんですよねｗ

広いような狭い業界。色々勉強してもっと詳しくなりたいです。

『二度目は早いよ』

某コミュニティ内・クリエイターの失敗談スレッドに載った名言。

 

某日、FLASHゲームのラフ画面を13〜15カット用意することになりました。

昼に言われて遅くなってもいいから当日中に欲しいとの事。

イラストレーターを使って早速製作。一つの画面を作ったらそれにパーツを追加して、また次のカットはそれに重ねたり減らしたりをしながら足していく作業。

そして、1ファイル分8カットを作り終えてちゃんと保存。一息。

 

続きのカットも、同じ画面から足していくので今の画像をひとつ残してあとを消してまた作業。そしてまた次のカット、という作業を繰り返す。

そして無事に2ファイルめも終わった〜と思ったところで私の左手が無意識に動きました。

ctrl+s、そう、つまり【保存】のショートカット。

まだファイル名を変更していませんでした（爆

さっきの作業分が全部上書きされて消えてしまいました…

製作をする方ならわかると思うのですが、ツールの選択など、よく使う作業はマウスではなくキーボードのショートカットを使うほうが効率が良いです。なので大体グラフィックを扱うときは左手がキーボードに乗っている事が多いんです。

ctrl+z、【前の作業に戻る】コマンドを使って復元を試みましたが、微調整をやりすぎたために欲しい画面まで戻ることができませんでした（泣

 

・・・と、いつまでも呆けていられないので、作り直さなければなりません。

救いなのは、主にパーツを足して作ってきたものなので、今度は主にパーツを減らしていきながら製作していけばいいわけです。助かった（と、ポジティブに自分ｊへ言い聞かせる）

そして失った分の画像を一度目の作業時間の1/5の猛スピードで作り上げて提出しました。

『二度目は早いよ』

この言葉を心に刻み込んだ某日の出来事でした。

 

Dreamweaver

個人的にはSTUDIO8をもっています。さすがにフォトショップとイラストレーターは高くて手が出ません。職場でだけ使用しております。

でも…職場のDreamweaverはMXです。

殆ど変わんないのですが、やっぱり変わっている部分ももちろんあるわけで。CSSに関していえばかなり強化されているわけです。

いや、むしろMXがひどいというのでしょうか、レイアウトが崩れまくって意味がないんですね。きちんとブラウザでプレビューしないと。

んでもってSSIなんて使っていたら、もうサーバに上げないとわからないんですよね、どう見えるのかが。

会社のソフト、バージョンアップしてください〜（泣

java scriptにご用心

webのお仕事と一言に言っても色々な内容があるわけで、サイトのデザインの特化したりFLASHに特化したりオーサリングがメインだったりとするわけだけど、仕事も一つではなく複数を抱えるのが普通になっていてたりします。

そんな中で自社でクライアントのサイト制作をして更新管理を行うものもあります。

その管理を新しく引き継ぐ場合等はきちんと内容の確認、レギュレーション（作成時のルール）等を理解しなければいけないのですが、忙しい等様々な理由でそれがまともに行われずに引き継いでしまう事も少なくない。

で、自分が受け持ったサイトにおいて、自分の油断からなのですが冷や汗な事件が起こってしまいました。

java scriptでのロールオーバーがワリと多い昨今、.jsファイルを別に用意して読みこませているわけですが、ロールオーバーしたい画像に番号をふります。

例）（一部）
/* ロールオーバー */
function ImgChenge() {
 var ID = ImgChenge.arguments[0];
 var N  = ImgChenge.arguments[1];
 document.images[ID].src = SwImg[ID][N].src;
}

まぁ、単純に画像に番号をふって入れ替えたい番号とセットにすればいいわけなのですが、そこでロールオーバーが増えれば番号も増えるのは当然。

なので、自分はそのずらっとあるリストの最下部にある数字の続きから作っていきました。20コぐらい。

そしてテストアップしてＯＫをもらい本サイトにもアップ。

 

…少し経ったのち、本サイトを何気なくチェックしていると、まったく関係のない部分のロールオーバーが私の作ったあたらしい画像に変わっている事を発見！？

な、なんで！？！？

 いそいでファイルを確認。さわってもいないjava scriptのソースを確認。

すると数字が降られているリストのまん中あたりに

[61]

[62]

[63]

[80]

[81]

[64]

[65]

・・・

ひ、ひどい嫌がらせのようじゃないですか！？

そうです、この大きな数字をふっている部分が私のものと重なっていたのです。

あわてて該当部分の番号を変更して事無きをえたのですが、ファイルは細部まで確認しなければ怖いなと学びました。（当然ですが）

 

その後の考察として、この部分はどうやら後付けで足されっぽい事がわかりました。ソースの書き方に他と異なる部分を見つけたのです。

きっと私の前任者もロクに引き継がれないままに更新管理をし、ぎりぎりの番号で作ってかぶってはいけないと思い、大きめの数字をふっておけば安心だろうと思ったのでしょう。

時を経てその番号に辿り着いてしまった私。そんなわかりにくい事しないでよ！と心で思いつつ、自分の注意不足に反省をした一日でした。

 

 

 

 

駆け出した

未熟な技術ながらも都内某所にてweb制作会社で働く事ができはや2ヶ月ぐらいが経ちました。

連日の終電帰りももはや普通のように身体が慣れてきました(笑)
いや、むしろ早く帰れると違和感を感じてしまう自分が怖い。

こんな生活はオススメできない。

それでもやる人ってやっぱり「好き」なんだよねこの仕事が。

案件が重なって忙しくてもjavascriptがうまく動いてくれなくてはがゆくなっても、乗り越えた時の充実感があるから続けられる。

ミスをして迷惑をかけた時にはおもいっきり凹みながらも。


駆け出しのwebデザイナーあらまるがそんな仕事上の喜怒哀楽な日常を中心にのんびりと更新するデス。