タブレット的なデバイスに最適なUIとは
半年ぶりの更新です。ほぼ放置でしたね…。
さて、日本でもiPadが発売されました。UMPCやPDAが全然振るわなかった日本ですが、iPadははたしてどれくらい受け入れられるのでしょうか？
ガジェット好きとしては気になるところです。
一応デザイナーである立場として、UIを設計する上でどのような特性を持っているか、つらつらと考えてみます。
CSS Niteに行っていろいろ考えてみた。
IA特集という事で、コンセントの長谷川さんがスピーカーになって、海外のIA事情について話してくれました。
今回は、日本よりも「IA」が認知され、活発な議論も展開されている海外の最新動向をご紹介しながら、参加者のみなさんと一緒に、IAの役割について考えてみたいと思います。
今年の5月に行われた、IA Summit 09での話題が中心でした。流石に世界中のIAやってる人が集まるだけあって、話題のレベルが全然違いますね...。
幸い、僕らの会社はIAに相当する職種が単体であるのですが、そこで議論されている、サービスの、かつ、ページのナビゲーションや単体の機能レベルではなく、より抽象的でスケールの大きな話が話題になっているようです。
今回のお話は、IA Summit 09のトピック的な内容だったので、広く浅く、といったお話でしたが、その中で、Big IAとLittle IAという話で多少考えてしまいました。
CSS Nite vol.36に行って来た
木曜の話なのに、今頃書いてます...。
元bAで、今は某メーカーにお勤めという、佐藤 伸哉氏を迎えて、インフォメーションアーキテクトについてのセミナーでした。
なじみのある言い方をすると、情報デザインという領域ですね。
自分がIAという単語を知ったのは、日経出版した「Strategic Web Design Vol.1」が最初でした。
当時は、まだwebデザインという業界(領域?)ですら未成熟で、情報デザインだけを行う専門家ってどんなスキルセットを持っているんだろうなぁ、と、全く人ごとのように思っていたのですが、あれから10年近く経って、専門分野としてなんとなく認知され始めたんだなぁ、と思うと、時の流れを感じます。
セミナーでは主に歴史の部分に時間を割いて、アメリカ西日本のSIPSが担っていた役割や状況などについてお話されていました。日本ですとSIerやハードメーカーが担っていた分野ですね。
その中で、IAがどのようなポジションに立つか、そしてどのような専門性を発揮するかについても話していました。
IAのアウトプットを見た時に、自分が想像していたアウトプットとそれほど違いがなかったので、正直ほっとしました。
今はなんとなくIAの領域に足を突っ込んだ仕事をしているのですが、いかんせん日本語の情報が少ないので、自分の仕事が正しいか常に不安だった所がひとつ解消されました。
セミナーの後の打ち上げにも参加しました。制作会社の方ばかりかな? と思っていたら、某編集部の方とか某Web担の方とかがいて、改めて CSS Niteの影響力を知りました。鷹野さん頑張っていますよね...。
今回は非常に実りのあるセミナーでした。IAについては、コンセントの長谷川さんがまた話すということなので、そちらも利きたいと思います。
GreaseMonkeyにようやく手を付けてみた
さわろうさわろうと思って、手を付けずじまいだったGreaseMonkeyにようやく手を付けてみました。
いやー、便利ですねー。失敗したなぁ...。
macでmampを使ってMT4をインストールしてみる
簡単にできるかな、と思ったらものすごく面倒だったので。
あ、今回はDBにmySQLを使おうと思ったので面倒になっただけで、SQliteとかだったら簡単にできると思います。
MTのバージョンを上げてみた
今年の年末年始の目標の一つに「ブログのバージョンアップもろもろをする」というのを立てていて、休暇最終日でなんとか終わりました。
いろいろ大変だろうなぁ、と思っていたのですが、やっぱり大変でした。
テンプレートの変更とかは後回しにして、まずは移行だけしました。
とりあえずざっくり手順はこんな感じで。
今更ながらSFCのサイトに触れてみる
本当に今更なのですが。
今は暫定的にHTMLのサイトとflashを使用したサイトの二つの誘導がされていますが、それまでは、まあ、なんというか、フルflashサイトを作るときにやってはいけない事を一通りやるとこうなりますよ、って見本のようになっていましたね…。
テクニカルな部分は的確に言及されていますので、ちょっとだけデザイン寄りな話を。
アカデミックにとんがった事をするのは全然悪くありませんし、一私企業の手先となってしまった身からするとうらやましい限りではありますが、とんがったナビゲーションを使う事とユーザーの環境やリテラシーの差異を図らずに走ってしまった感はあります。
クリエイティブディレクションのポジションに当たる人がうまく舵取りできたらよかったのですが、そこがうまくできずにアンバランスなデザインになってしまっているのが残念なところです。
内部で作ったか制作会社が作ったか判断に迷う所ですが、個々の作り込みは細かくされていて、じっくり見るとその思いが伝わってくるように見えるのに、うまく伝わりきらないのが勿体ないなー、と思いました。
ただ、SFCのサイトはリニューアルのサイクルが早く、アグレッシブに新しい取り組みを行っていますので、今回の教訓を活かしつつ、その更新ペースは保ってほしいところです。
あと、多少気になったんですけど、慶應のサイト全体のVIって、特にないんですね…。ちと勿体ない。
CSSのブラウザ分岐
最近人に聞かれたので漠然と考えていましたが、結構方法があるなぁ、と思いました
ほぼすべてのブラウザを確実にサポート
- PHPやperlなどのサーバサイドスクリプトでUAを判定
反則技のような気もしますが…
概ね確実にブラウザをサポート
- IE6/7…conditional comment
- IE5.5/5…分岐用CSSを用意してBand Pass Filter
- macIE5…分岐用CSSを用意してholly hack
ほぼ全てのブラウザをサポートするけど、ユーザー環境で多少動作が変動
- IE6/7…conditional comment
- その他…javascriptでUAを判定
あまりブラウザをサポートしていないけどファイル構成はシンプル
- IE6/7…selector hackを使ってCSS内にブラウザ対応用の指定を記述
- その他…切り捨て
ウェブデザイン技能検定をやってみた。
web検と同時多発的にできているのがちょっと気持ち悪いですが、国家規格として認定されている「ウェブデザイン技能検定」3級の練習問題が公開されていたのでやってみました。
学科と実技に分かれていて、学科はウェブデザインに関わる基礎的な知識を確かめる問題で、実技はあらかじめ用意されたHTMLやCSSに簡単な修正や追加を行うものでした。
学科は以前に某社の中途採用試験で受けた問題に非常に良く似ていたのですが、何かひな形になるような問題が過去にあったのでしょうか。
また、どちらかというと、ISOとかJISといった規格に書かれている事を問う問題が多かったです。問題に解釈が生じにくい手堅い感じでした。
で、結果はというと、学科は30門中27問正解という、あまりよろしくない結果でした…。
以下、間違っていた問題です。
- HTMLやCSSがISOか業界標準か国内ウェブ基準(何?)という問で、ISOという事を知らずに業界標準と回答してしまいました…。
- 無線LANのセキュリティに関わる問題でした。SSIDが何かも知らず、適当に答えたら案の定間違っていました
- アクセシビリティに関する問題で下記の中から適切なものを選択するという問題で、
- Webサイトのアクセシビリティを高めるには、できるだけデータ容量を抑えた構成をすべきである
- Webサイトのアクセシビリティを高めるには、トップページには高解像度の画像や動画など、見映えの良い大容量のデータを配置すべきである
- Webサイトのアクセシビリティを高めるには、トップページの他のページでメニューやナビゲーションを個別にデザインすべきである
- Webサイトのアクセシビリティを高めるには、利用者に飽きられないように毎回違うインタフェースをランダムに提供すべきである
まず2と4を外し、アクセシビリティ=スクリーンリーダー対応、という考えがあったので、あまり関係ないであろう1を外して3を選択したのですが、正解は1でした。
確かに、アクセシビリティ=マルチデバイス対応(厳密には違います)、と考えると1ですね。
あと、実技については、仕事でHTMLに触っていればまず間違う事はないようなレベルの問題でした。というか、間違いようがないですね。
まあ、ウェブデザイン技能検定に合格するのと仕事としてwebデザインができるのは全く別の話ですが、webデザインを仕事として行うのであれば最低限知っておいてほしい部分はおおまかに押さえられていますので、人のスキルを見るふるいとしては使えると思います。
コーディングスタイルについて
議論し尽くされた話ではありますが、自分の整理のために。
ダイナミックにしろスタティックにしろ、webページはおおむねHTMLで書かれる場合が多いです。
そして、そのHTMLを設計したり書いたりするのはwebデザイナー(笑)とか、マークアップエンジニア(笑)であることが多いです。
最近はセマンティックウェブとかmicroformatsといった、メタデーターを付与することを前提とした概念や仕様ができつつあるので、webアプリを開発したい設計したり手がけたりする人たちにとっては、HTMLは「マークアップ言語」で「メタ言語として使える言語」であることは、以前に比べて浸透してきていると思います。
しかし、実装しない立場で開発に関わる人や、過去に習得した手慣れた手法(テーブルレイアウトとかイメージマップ一枚ものとか)を踏襲する人たちに、それを説明して納得してもらうことはなかなか難しいものがあります。というか、まず納得してくれません。
そこで、理解してもらうのがなぜ難しいかと、どうすれば歩み寄れるかを考えてみます。
web標準的なコーディングスタイルをなぜ受け入れてもらえないか
- 習得に時間がかかる
- テーブルなんちゃらはとウェブ標準的な記述は、一見同じ言語を使っているように見えても実際の作業内容や方法は全く違います。例えば、同じ日本語でも女子高生の会話と自分の両親の会話の語彙が全く違うのと同じ程度には違うでしょう。
頑張れば3日くらいでできるようになると思いますが、その時間を作る方が難しい場合が多いと思います。 - コーディングスタイルを変えることにメリットを見いだせない
- 当然ですが、ワイヤーフレームや仕様書には、実装について書かれることは殆どありません。
そして、web標準的なコーディングスタイルはあくまで概念であって仕様でも規定でもありません。
さらに、SEOやSEMに効果がある、といいますが、それも本当に有効かは疑わしいものがあります。
そのような拘束力の弱い概念なので、よほどのメリットがない限り、変える必要はないと判断されても仕方ありません。 - 直近の仕事が山積みで余裕がない
- まー、ありがちですね...。コメントは割愛します。
- 概念的である
- 2項目目と被りますね。
明確に目に見えるものではないので、理解できても納得できない場合が多いと思います。 - モチベーションが低い
- まあ...、あまり言いたくはありませんが、下流行程なので言われたままに仕事をする、ってデザイナーも中にはいます。
そういう意識がオペレーター的な仕事を増やすという認識はないんでしょうね。きっと。
どうすれば受け入れてもらえるか
じゃあ、これらの項目を単純に反証してみます。
- 習得に時間がかかる
- ポイントを押さえれば、1日で覚えられるでしょう。
しかも、一度覚えると応用が利くので、今までより作業効率が上がる場合の方が多いです。
ポイントとしては、こんなところかと。- HTML ... 「マークアップとは」「XHTMLのsection要素の概念」「タグリファレンス総ざらい」
- CSS ... 「ボックスモデル」「floatとposition」「clearfix」「ブラウザの各種バグとハック」
- コーディングスタイルを変えることにメリットを見いだせない
- プロのプライドに訴えかけるのがいいのかなぁ...。
HTMLの単純化(と、それに伴う作業の圧縮)、振る舞いの一括管理/変更、メディア対応などありますが、そもそも仕様として間違っているスタイルで作業をすることを恥ずかしいと思わないのかと、訴えるというのはどうでしょう？
うーん、響かなさそう...。 - 直近の仕事が山積みで余裕がない
- メディアにおける広告料の上昇とか世間へのウェブへの認知度を持ち出して状況の変化を強調し、それについていけない事への危機感を煽るってのはどうかなぁ。
- 概念的である
- まー、そもそもハイパーテキストそのものが分かりにくいからなぁ。分かってくれとしか言えないような気がします。
あとは、コーディングスタイルの話についてこれなかったらCGMなんてもっと理解できないと思うので、仕事として向いていないような気がします。 - モチベーションが低い
- 来る業界が違うような気が...。
同じデザインの仕事でも、もっと状況や環境が安定している業界はありますよね。
うーん、とってもネガティブですね...。しかも反証になっていないし。
まあ、後３年もしたらこういう話も与太話になってくれることを祈りつつ、今の状況確認としておきます。