Ajaxを取り入れたSONYのコーポレートサイト

AppleやGUCCIのサイトのように、Ajax＆エフェクトを駆使したFLASH的なサイトを探していたら、SONYのコーポレートサイトに出くわしました。9月頃にFLASHをやめてAjaxに移行してリニューアルしてたらしいです。（話題になってたっぽいですね。。）

http://www.sony.co.jp/

これくらいのクオリティで作るとFLASHに近い感じで気持ちいいですね。
（さすがに派手なエフェクトはFLASHには敵いませんが・・）

スムーズスクロールの表現

Javascriptによるページ内リンクをスムーズスクロールにする動作はよく見かけますが、「KAZUMiX memo」というサイトのDEMO動作が大胆な使い方で、こういう使い方もおもしろいなと思いました。

http://d.hatena.ne.jp/KAZUMiX/20080418/scrollsmoothly

配布しているライブラリの仕様も、JSファイルを読み込むだけで、ページ内リンクがスムーズスクロールになる仕様なので、簡単で使いやすいです。jQuery, prototyp.jsなど他ライブラリを必要としない点も魅力的です。

画像主体の紙っぽいサイトで、スムーズスクロールを上記DEMOみたいにダイナミックに使ってみると、動きがでて良さげですね。

Dream Weaver CS４ 新機能

Dream WeaverのCS４の新機能についての記事。

http://www.adobe.com/jp/devnet/dreamweaver/articles/dwcs4_publicbeta.html

プレビュー機能「Live View」や、CSSの内容がポップアップでプレビューできる「Code Navigator」がコーディング時間の短縮に活躍しそうです。

アンカーリンクやフォームに使えそう - Seek Attention

コリスさんの記事で見つけた気になるJSエフェクト「Seek Attention」。

注目させたい場所にスムーズスクロールし、

さらに該当場所を白抜きして目立たせるエフェクト。

Seek Attention デモページ

動作もいくつかバリエーションがあるし、アンカーリンクに活用すれば、ページ下部へのアンカーリンクもユーザーに判りやすくできそうです。フォームのエラー画面とかにも使えそうです。

主要ブラウザで上記デモページをざっと動作確認をしてみました。

動作OK

IE6, IE7, FF2, FF3, Safari1.3, Safari3, Chrome, Opera9

動作NG

Netscape7, Opera9.5

ほとんどのモダンブラウザで問題ないようです。

（Opera9.5もスクロール動作が一旦ページトップへ動いてしまうバグ以外は問題ないようです）

Ajaxに使えるローディング画像

Ajaxの通信中のローディング表示使えるアニメーションGIF作成サイト。

http://www.ajaxload.info/

CSSコーディングのメリット・デメリット

ここ数年、世間の流れではCSSコーディングが主流になっていますよね。

僕自身もクライアントから特に指定が無い限りは基本的にCSSでコーディングしています。

でもたまにお客様から「なぜCSSで組まないといけないんですか？」という質問を受けます。

まぁこの質問に対してあげられる回答としては、以下のようなものがあがると思います。

• ソースが適切マークアップされているので、
  どんな環境（プログラム）からでもスムーズに読める。
  
• ソースが読みやすいのでSEOにも適している
  
• デザインとコンテンツを別に管理でき更新が容易になる
  
• コンテンツが適切にマークアップされていれば、
  アクセシビリティがよくなる（音声ブラウザ対応など）

まぁ他にもいろいろCSSでコーディングするメリットはあると思います。

上記のようなメリットを見るとなんだかいたれりつくせりで、CSSで組むのがやはり当たり前って気がしますが、僕個人の見解としては一概にそうとも言い切れないのでは？と思ったりもします。

以下は実際に僕が携わった案件を通してデメリットなのでは？と思った事柄です。

（ひとまずざらっと記して細かいことは後述で。）

1. サイトオープン後、運用にあたって、コーディングに関するリテラシーがないと編集作業がとっつきにくい。（お客様自らで編集、更新をする際など）
   
2. CSSコーディングはプログラム的な構築方法なので、最初にデザイン設計を確実に行わなければ、そのメリットが発揮できない。
3. CSSコーディングもさまざまな方法が普及したのでデザインの再現率は高くなったが、それでもまだ自由度が低い。
4. マークアップを適切にすることが前提だが、現状普及している(x)htmlのバージョンではマークアップのタグ種が不十分。

と、ぱっと思い浮かんだことを書いてみました。

1.に関してですが、サイトをクライアント自らで運用更新するのはよくあるケースだと思います。

TABLEコーディングのようにデザインがHTML上にあれば、オーサリングソフトなどを使って見たまま直感的に編集できると思いますが、CSSコーディングの場合はそう手軽に編集できません。オーサリングソフトもCSSサポートはだいぶ充実してきているので、ある程度シンプルなデザインなら編集しやすいと思いますが…。

下手にCSSを編集してしまうと他ページが崩れてしまったりしますし、既存CSSをいじるのが恐いからといって新規にCSSを追加して、それが繰り返して行われていってしまっては最初に綺麗に設計した意味がなくなってきます。そんなこんなでソースやファイルがぐちゃぐちゃしてしまうなら、最初からTABLEコーディングの方がある意味シンプルで判りやすいです。他ファイル干渉もないですし。（コーディングマニュアルを納品するって手もありますが、クライアントにWEBマスター的な役職の人がいれば飲み込みは早いでしょうが、コーディングになじみが薄い方にはおっくうな気がします・・）

続いて2.に関して。

デザイン設計がきちんと行われCSS設計をきちんとやらないと、初期構築の際の多人数での作業が難しいですし、運用の際にもソースやファイルがごちゃごちゃとしてきてしまいます。

プログラム的に考えると、作業分担して行う場合に各々思うまま組んでしまうのでページによって仕様がバラバラ。運用後にどんどん仕様追加。といった状況ではないでしょうか。

3.に関して。

CSSの技術も向上しましたが、まだ表現が弱いところはあると思います。

DIVタグを多用したり、Javascriptで補ったりと工夫をすればフルCSSで再現できないことは無いですが、それだと結局ソースも複雑で本末転倒な気がします。

各ブラウザが最新バージョンのCSSを取り入れ動作統一してくれれば、できることが増えるのですが。。

4.に関して。

現状普及している(x)htmlのバージョンでは、「これって文法的にマークアップは何？」って要素に出くわします。紙っぽいデザインで「文法どうこうないんじゃない？」ってページにマークアップするのってどうなんでしょう。。数年経てば次世代のバージョンが普及して、もう少しマークアップの幅は広がりそうですが。

まぁそんなこんなでCSSコーディングのデメリットを書いてみました。

（自分で読み返すとなんだかアンチな感じですね・・・）

「コンテンツ内容が魅力的」これをバックアップする意味でのWEB標準。と思う今日この頃です。