その他制作Tipsの最近のブログ記事

納品期日間際というのに、作業場のエアコンが故障したり、銀歯取れたり、色々不幸に見舞われてます。
どうにもならない不条理に少しでも抗う為に、人間は知恵を振り絞る・・・。という訳で。

システムを自力で組むよりは、他人の力（オープンソースなりASPなり）を利用するというのが、やはり効率的な訳です。案件が舞い込んでからでは遅すぎるので、様々なASPやオープンソースを評価しておこうという事になりました。特にECがらみ。

オープンソースではEC-CUBE、ASPではこの前教えてもらった、Shop-Maker、カラーミーショップなど、時間を割いてでも使ってようと思います。

簡単なフレーム処理やイベント処理でActionScriptを利用するものの、
インタラクティブなアニメーション表現をActionScriptで表現するのは、
それを専門にしている人でない、制作以外の工程も一貫で携わる必要
のある自分には苦労が多い。
動的な表現も大抵はオーサリングの機能（トゥイーンを利用したフレームアニメ）で
事足りるが・・・。スプラッシュムービーであればこれで充分。

最近興味があるツール”Flash Catalyst”。簡単に言うとコードを
書かずに、UIに多彩なインタラクション要素を追加できるらしい。
ツールに慣れる自体で、それ相応の労力は必要だが、ActionScriptのロジックと
発現するアニメーション効果の相関を試行錯誤するよりはよっぽど効率はよさそうだ。
という訳で、時間を取って評価してみようと思う。

最近の流行りといいますか。グリッドレスなデザインの装飾部分の制作には
様々な選択肢があります。
自分はCSSのネガティブマージンを利用しています。

やり方は簡単。
CSSで装飾画像のmarginに マイナスの値を指定するだけ。

コツはIE６対策にブロック部分に　zoom:1　を
画像部分に　position: relative; を指定しておく。

バリデータはサーバサイドよりも、クライアントサイドで完結していた方が、
ユーザビリティ的にも、開発者にとってもメリットが大きいと感じる（サーバ側でも対策するが）。
と言うことでバリデータのライブラリを探して、一番よさげなものに辿り着く。

「jQuery Inline Form Validation Engine」
これは、テキストフィールドだけではなく、radio,checkbox項目のチェックや
他の項目との比較、その他もろもろ・・・ほとんどすべてのチェック方法を指定可能。
該当項目へのツールチップ表示なども完璧。
ドキュメントは英語。

使い方：
ヘッダに下記を指定

フォームの項目にチェック方法指示
<input class="validate[required,custom[onlyLetter],length[0,100]]" name="firstname" type="text" />

チェック方法
optional: Special: Only validate when the field is not empty
required: Field is required
length[0,100] : Between x and x characters allowed
minCheckbox[7] : Set the maximum checkbox autorized for a group
confirm[fieldID] : Match the other field (ie:confirm password)
telephone : Match telephone regEx rule.
email : Match email regEx rule.
onlyNumber : Numbers only
noSpecialCaracters : No special characters allowed
onlyLetter : Letters only
date : Invalid date, must be in YYYY-MM-DD format

WEBの制作で時間の多くを占める環境依存要因対策。
クロスブラウザであったり、サーバ環境であったり。
クロスブラウザで言えば、IE6が元凶の様な気も・・。
現在はテスト環境と本番環境で別のレンタルサーバを使用した
WEBシステム開発での苦労に見舞われている。

Perl、データベースのバージョンの相違・・モジュールのインストールの有無・・
それにしても最近気になっているのが、エンコードEUCでの文字化け。
今現在は、ソースファイル自信もフォームから受け取るデータもEUCで
扱っているのだが、特定文字列でのみ文字化け・・。
SHIFT-JISと大差ないんじゃ。

例えば”希望”をUTF8のページからフォームで受けて、EUCに変換して
表示すると化ける・・というより、なぜか変換されない（その部分だけUTF8のまま）。
特定文字列のみなのでロジックがおかしい訳ではなさそう。・・理由がよくわからん。

さらに環境依存が激しいのがモバイルなんですが、
最新のモバイル制作事情に詳しい資料を取り寄せた所、
この環境依存対策の事で８割埋まっていた。
携帯キャリアさんにはもう少し考えて欲しかったと思う。
・・と不満ばかりも言ってられないので、回避策の引き出しを
増やしていこうと思います。

JavaScriptは大学時代から触れている言語なのですが、、、
どうにも最初のイメージが悪く、習得する気無くその都度使いまわしきた様な気がします。
そもそもクライアントサイドでのみ、かつスクリプトのみで行う処理はたかが知れていると
大昔感じて以来、あまりいじらなかったのですが・・

最近のライブラリ群には驚かされます。
動画と音声以外は大抵Flashと同等の事が実現できると言っても
それほど過言ではないのでは・・。
IT業界には昔からいましたが、WEBは比較的最近なので、JQueryであるとか
Prototype.jsであるとか、便利なライブラリ群を知ったのもつい最近なのです。

と言っても、これらを使う目的のメインはやはりユーザビリティの向上。
根幹のシステムには従来どおりのサーバサイドの言語で開発。
このユーザビリティの向上と、動的コンテンツによるサイトのデザインレベルの向上。
この一手間がサイトの利用者の満足度、コンバージョン率を上げるのだと感じてます。

最近ではWEBサイト制作後にIE6,IE7,Firefox3,Chrome等でデザインの検証を行ってますが、まぁ、最初はかなりズレますよね。

ベースはFirefoxで見ているので、それを特にIE6で見ると大概ひどい事になっていて、それから修正した後、Firefoxに戻るとまたズレる・・みたいな。

この作業って結構パズルみたいで以外に楽しかったりするんですが、バグが起因で再現率が100％じゃない時は、ストレス100％。

閲覧する人のせいにする訳にはいかないので、そのバグをも考慮したCSSにする訳です。特にIE6はバグが多い・・。

今、解いているのがFirefoxのTableのborderが消える現象。
ローカルだと消えなかったりするのが不思議。

こういう意味でもクロスブラウザ対策ばっちりのテンプレートとかCMSとかたまに使いたくなりますね。
うちは一から手打ちがモットーなので（ソバみたい）、毎回このパズルを解く訳です。