っていうはなし。
最近 Web サイトのリンク集なんかの RSS を読みはじめたのだけれど、結構そんなのが多くて。
レイアウトが斬新で、「どんな UI なんだろー」とか思ってワクワクしながらコンテンツを見ようとすると、画面真っ白。みたいな。
ホームだけやたら凝ってて中身が普通だと、かえって期待感を裏切られる感がある。
逆に UI やビジュアルが凝りすぎていると、コンテンツに意識がいきづらし感じもする。
まあ、バランスということかしらん。
ただ、なんとなくそう思っただけ。
]]>っていうはなし。
最近 Web サイトのリンク集なんかの RSS を読みはじめたのだけれど、結構そんなのが多くて。
レイアウトが斬新で、「どんな UI なんだろー」とか思ってワクワクしながらコンテンツを見ようとすると、画面真っ白。みたいな。
ホームだけやたら凝ってて中身が普通だと、かえって期待感を裏切られる感がある。
逆に UI やビジュアルが凝りすぎていると、コンテンツに意識がいきづらし感じもする。
まあ、バランスということかしらん。
ただ、なんとなくそう思っただけ。
]]>今までは .section をチャンクレベル1としていましたが、それがひとつ下のレベルに下がります。
実際コーディングしてて、も一個ほしいとか思うこともしばしばだったのと、 HTML5 に合わせる形での追加です。
あとこないだ IE でこのサイトの HTML5 のページを見たら思いっきりヘッダーとフッターが壊れてました。
けどいいんです。仕事で苦しめられている分、個人的にはガン無視してやるのです。
サイトのターゲットも同業者なので、きっとモダンブラウザを使っているはず。
でもブログのほうは微妙なので、 XHTML1.0 のままにしとこう。
好きだから、幸せだ。
好きだから、徹夜だって平気。
とか。
好きだから、では目の前のことしか見えない。
ラーメンが好きだから、ラーメン屋になる。けど、みんなが自分の好きなラーメンが好きなわけじゃない。一定以上の趣向にあった味をつくり、一定以上の顧客を確保しなければ、ラーメン屋はツヴれる。
かといって迎合してもいけない。迎合すると、誰からも嫌われないけれど、誰からも好かれない。八方美人で結局は同じことになってしまう。
つくって売る。というのが成立するのは、その行程において、専門的知識、技術を要し、かつ、できあがったものが一定以上の、つまり支払うコスト以上の利益を産むものでなければいけない。
なにをつくっているのか、はこのさいどうでもいい。
重要なのは、利益を産むための行程において、自分がどういった役割をおっているのか、ということじゃなかろうか。
それが見えないと、仕事はツラい、
例えばホームページをつくる、ではいけない。Web を使ったビジネスモデルをどう形成するのか、を、かんがえないといけない。
目的が明確であれば、失敗しても効果の測定ができる。それは失敗ではなく、成功のための糧になる。
難しくかんがえてはいけない。最初は小さな利益でいい。目に見えれば、そこに群がるいろんなひとがでてくる。 Twitter とか。別に、ただ何行かの文字列を保存していくだけのモンじゃん、とか。でも、それは、まぎれもなくイノベーションになる。
別にニュータイプになりたいわけでもイノベーターになりたいわけでもないけど。
]]>と、マーネージャークラスなら答えられて当然というレベルの質問だけれど、どうもぼくは考えが浅いので。うまく答えられるだろうか。
まあ、ゆるゆるろ考えていこうかと思う。
]]>ブログはまだ XHTML 1.0 ままだけど、他のページは ほぼHTML5 に変えた。
今後ちょろちょろ HTML5 まわりのテストをやるにあたって、便利だし。
つかいやすくなったかといえば、つかいやすくなった。
前はエンティティが管理画面でテキストエリアに入った場合に実体化してしまったり、 </textarea> がはいった場合にそれ以降のコードがでなかったりと、ほぼ致命的な問題があったりして、でもどうしたらいいのかわからずに、ほったらかしにしておいたのだけれど、今回はそれも解決した。まあ、単純に str_replace しただけですけど。
半年くらいかけてやるとかいいつつ、一月くらいでおわった、別に手を抜いたわけじゃなく、自分用なので案外やることがなかったので。
次は ActionScript で遊んでみる。
できる人のコードをみるのは勉強になる。基本的なとこ以外は自己流でやってきたので、どうもクセがあるっぽい。
ああ、あと Felisi とかいうとこのバッグ買った。前のはすっかりツブれてしまったので。しかし思いの外高いね。バッグって。
管理するものが増えたので、入力項目が増えた分、前のものより各要素の重みづけを明確に行いそれらを視覚的に表現した。
入力項目とは関係のない上部の要素の高さをなるべく少なくするため、メインナビゲーションを既存の上部の縦配置から左部の縦配置へ変更。
また、ドキュメントの新規作成と、更新では入力の必然性のある項目数が異なると考えられるため、目的によって各項目の表示、非表示が切り替えられるようにした。
まあ、こういうのはつくってからまた、テストしてみるものなのだろうけど、自分がユーザーで。開発者で、デザイナーということで、テストは出来上がって使ってみてからやろうかな、とか。アジャイルで。
既存のもののコードはあまり汎用性を考えていなかったので、基本ほぼイチからつくりなおしだけれど、まあ、そのへんは今回の課題として、先に諸々考えてドキュメント化し、それからコーディングを始めるというプロセスにしたい。
結局コーディング終わってないものの、3ヶ月前に似たようなことをしてみて、「ごく単純な交通信号機制御シミュレーターの設計」というのをつくってみたけれど、やっぱり結構実装段階でポロポロでてくる。これは自分のスキルがないせいなのか、それともこんなものなんか。というか両方っぽい。むしろ前者が大きいと思う。
設計書や企画書、仕様書等のドキュメントが長大になるのは御法度だというけれど、最初のものは極シンプルだけど、必要なことすら書いてない。
次に書いてみたドキュメントは、だらだらとコードが書いてあったり、変数の対応表が書いてあるだけで、ほぼ無意味。変数どうのは実際のコードのコメントに書いておくべきだと、スゲー当たり前のことに気づく。
最高のドキュメントは A4 1枚で概念を伝えられるものだというけれど、それは流石に無理だね。
今回のドキュメントもそうたいしたもにはなりそうにないけれど、必要なものと不要なものがみえてきたってことで、以前よりはまだマシにしたい。
]]>現在の問題点としては
っていうのが思いついた。
改善策として
といった感じ。
あとせっかくなんで、全部 HTML5 にしてしまおうと思う。
プログッレッシブ・エンハンスメントで、モダンブラウザには視覚的にも、ちとリッチにしてみたり、必要であれば UI で Canvas とかも。徐々につかっていかにゃあ、時代遅れの男になったら怖いけん。
マークアップの学習もかねて。
次は UI 設計。
]]>とりあえずは以下の3つで今年はがんばってみようかと。
いちおうこれで HTML CSS JavaScript GUI サーバサイドの言語 ActionScript とやってきて、これやったらなんとなくひととおりは理解できるかな、っていうことで、
前に「10年やってスタート地点に立てるという」とかもいいつつ、人生短いし、師匠もいないので、駆け足で5年でスタート地点に立とうという計画が、今年で一応完了する予定。
一昨年くらいに古いノートパソコンもらったんで、そいつに Linux をいれつつ、がんばってみる。
去年つくた「Web サイト管理アプリケーション」は正直ヒドいもので、自分のスキルのなさを実感した。
今年は半年くらいかけて、全体設計から部分のディテールにまでこだわったものがつくりたい。
今のやつの問題点と改善点を考慮しつつ、構想中。今週末にはグランドデザインを終えて、マイルストーンや、設計プロセスについてのデザインをして、再来週あたりからつくていけたらと思う。どうもやっぱりデッサンというのは大事なようで、画家が1枚の絵を書くために何十、何百枚もデッサンを必要とするように、設計にもそういったディテールの精度みたいなものを追求できるようになれたらと思う。
Flash Math & Physics Design:ActionScript 3.0による数学・物理学表現[入門編] という本を去年買ったので。アニメーションやプログラムによる描画は今後 Canvas や SVG などでも使用されるだろうし、基本数学はワカランチンなので、考え方として吸収しておきたいな。なんて思って。
まあ今年までは丁稚のつもりで勉学にいそしんでいそしんで。
]]>Web のアプリケーション化というは HTML5 によって加速するとかいうはなしもあるけれど、やっぱり基本は情報共有としての Web で、アプリケーション化というのは、 Web のひとつの使い方でしかないと思う。
ただ、肥大していく情報をどうやって整理し、どういったインターフェースでそれにアクセスするのかということは、今後益々重要な課題になると思う。
デバイスの多様化によって、ベーシックな部分の標準化というのが、もう避けて通れないものになっている中で、技術があれば成立していた Web サイトの制作は終わって、法律的な意味での標準に対する知識というのもなければ、成立しなくなるんじゃなかろうか。
また、実制作における分業化が進み、ゼネコンじみた企業と、その下請けのその他という産業構造になっていくのかというのは随分前からあるはなしのような気もするけれど、最近の仕事をみていると、そんな感じがあったりなかったりもする。
ただ Web の場合、一旦データベースなりなんなりに、コンテンツをデータレベルにまで還元して格納してしまえば、下請けの仕事というのはあまり必要ではなくなるため、仮に下請けによる量産という構造ができあがったとしても、それはそう長くはもたない。
その中でどういった分野で生き残っていくのかという戦略なしには、組織の維持が難しい。
母体が大きくなければ、何でもできますというのは不可能だし、何でもできるというのは個人的にはあまり好きでない。
むしろ、中・小規模の組織がプロジェクト毎に連携して仕事を行うという構造のほうが、 Web っぽいと思う。
それぞれの組織がそれぞれ得意な分野があって、新しい組織が新しい分野をつくっていく。
そいで、既存の技術と新しい技術がコラボレーションして新しいビジネスモデルができる、みたいな。
とりあえず思いつくのは
とか。
まあ、戦略策定は経営者の仕事なので、あれですけど、来年はそんなはなしが聞けたらなぁとか思う。
]]>ライブラリをつかうと、ほぼなにも考えずにできるので、ちと怖い。最近 JavaScript を少し忘れそう。
まあ、将来的には標準化されるというのを考えれば、変にブラウザ毎の分岐を覚えるよりも、ロジックを考える力を身につけていったほうがいいとも考えられるし。
]]>RIA が一般的に使われ始め、UI デザイナーとしてのスキルがさらに求められるようになったWeb のデザイナーのための本が2冊。
SEO というビジネスに結びつきやすい側面からみた技術書が1冊。2010年ももう来月にくる。そんな次の Web デザインのためにぜひ読んでおきたい3册。
じゃのう。
ウェブのインタラクションをよりリッチにするためのパターン、ベストプラクティスをまとめた書籍です。ドラッグアンドドロップ、オーバーレイ、展開／折りたたみ、アニメーション、ライブプレビューなど、75以上の重要なパターンが「直接的なインターフェースを作ろう」から「すばやく反応しよう」まで、6つの原則のもとに整理され、操作の概要、利用すべき状況、そしてアンチパターンまで、丁寧に解説されています。すべての解説例が、Yahoo!、 Google（Gmail、Google Maps）、Flickrなど実際のサイトを例にしていることも大きな特徴です。エンジニア、デザイナー、マーケティング担当者などウェブに関わるすべての人が共通の基盤を築くために欠かせない一冊となることでしょう。本文オールカラー。
ユニバーサルデザインの構造的な原則をウェブアプリケーションに適用し、できる限り多くの人々がコンテンツを利用できるようにする方法を紹介する書籍である。パソコンのブラウザ以外の手段でウェブにアクセスする際、ブラウザごとに異なるインターフェースを用意しないで済むためのデザインから、動的なコンテンツを閲覧可能にするためのWAI-ARIAへの対応やウェブアプリケーションにJavaScriptを組み込む際のポイント、またFlashや Flex、Silverlightなど、アクセスしやすいRIAのについても詳述する。日本語版では、日本国内での状況を付録として収録している。
Webサイト最適化技術を総合的に解説した手引書。検索にヒットしやすく操作性がシンプルで潜在顧客を購入者へと変える魅力的なWebサイトの作成方法を「SEO的なオンラインマーケティング」と「Webサイトのパフォーマンスチューニング（バックエンド/フロントエンド）」という2つの側面から解説します。検索順位を上げてアクセス数を増やし、コンバージョンレートやリードを高め、ユーザーを逃さなぬようサイトをスピードアップし、ツールを使ってサイトの改善効果を測定するなど、サイトのパフォーマンスを改善するためのさまざまなテクニックを紹介します。
DOM にせよ htmlSQL にせよ、こういったかたちで HTML を扱うと、それがただ描画のためにあるのではなく、共通の情報資産としてあるということを再認識します。
情報の構造化というのは、その情報にたいするアクセス構造の設計です。
Web サイトはドメインという概念空間での文脈をもち、それらはプログラムの計算予測性を裏切らないかたちでの法則の設計ということが求められます。個々のドキュメントの構造のみならず、そういったドメインレベルでの構造設計というものは、今後、 Web の可能性と広げていくためには欠かせないことだと思います。
HTML では、明確にその全体の文脈を記述することはできないようですが、そのひとつの手段として、 rel="prev" rel="next" などを記述することで、前後の文脈を関連付けるはできるようです。XML ベースでは、 RDF もしくは XHTML のモジュールとして RDFa などを使用することで、文書間の関連付けということが可能になるようです。
これらは現段階では一部のエージェントがナビゲーションを構成するといった使われ方しかされていないようですが、今後、意味解析の技術が発展すれば、前後のドキュメントの文脈から、現在のドキュメントの含意を推論することで、より精度の高い検索システムの構築が可能になるなど、社会全体の利便性を向上させる可能性を秘めていると思います。
たかが HTML かもしれません。しかし、全ての基盤がその文書構造にあるとも言えます。
]]>以前あったものは、 CSS のプロパティの設定が既にされており、新規に作成する際に無駄なプロパティの設定を削除する必要があったため、あまり使い勝手がよくなかったので、今回はプロパティの設定を最小限におさえています。
また、 HTML ファイルは id / class の命名規則に記述されたすべての id と class を指定した構造をつくってあり、 CSS も同様に id と class を記述してあります。
これを基にモジュールを作成することで、構造とスキンの一貫性を保持し、コーディングの効率を上げる事ができます。
クラス名も多少の変更を加えました。いくつもバリエーションのでてくるブロックレベルエレメントの class 名を *-[alphabet] ( 例 : unit-a )とすることで、より柔軟な追加を可能なようにしています。
JavaScript は jQuery を読み込んでいます。
また。画像ファイル名に _on と _off を使用することでマウスオーバーで画像の切り変わるスマートロールオーバーを記述し、アンカーでのページ内の移動をアニメーションで行う、スマートスクロールを to-top class に設定しています。
]]>Thunderbird 3 いれてみた。家だと Gmail なんで、会社のに。
Gmail は便利だけれど、 Outlook とかと GUI レベルでは基本大差ないように思う。
実際、他のメーラーも「メーラーってこんな感じ」っていう感じで、正直不便もさほど感じず、そういうものって思ってた。
ただ、もちろん Thunderbird 2 を使っていたのは、 Outlook よりは全然使い勝手がよく、洗練されていたからではあるけれど、それでも今までメーラーのイメージの中にはあった。
でも、どうやら Thunderbird 3 はちょっと違う。タブ機能や複数のメールの内容をリスト表示など、メールをただ送る、受取るというのではなく、メールはひとつの情報のアーカイブで、それはある意味で資産であるという認識で設計されているように思う。
実際、文字列検索をして探すこともままあるし、過去から現在にいたる議事録的な役割もあったりで、そういった考え方はスマートフォルダという機能にもみてとれる。メールという概念の変化に確実に対応している。
当たり前だろ思ってて、不便がさほどないからといって、それをそのまま受入れていてはいけないな、って思わされた。
]]>非常口、トイレ、これらは建物に入ればまず第一に確認すべきものでもある。
では、場所とは何か？ 絶対的な場所というのは存在しない。なぜなら場所は自己とそれを繋ぐ空間のことだからだ。
それを繋ぐ空間も場所というのは、例えば、木星を場所としては認知できない。それはそこに行くことができないからで、ヒマラヤや網走ですらぼくにとってはただの名詞でしかない。
これにたいして近所のコンビニは場所だ。待ち合わせでつかうあの店も場所として認知している。場所とは具体性をもった空間であり、同時に場所というのは存在しない。あくまで、ぼくや彼（彼女）の頭の中に概念としてあるにすぎない。なぜならそれは常に動き、壊れ、消えるからに他ならない。だが仮にある店がなくなっても、場所という概念は、かつてそこにあの店があった場所としてのこる。それはつまり場所とは緯度経度という地点ではなく、概念空間における認知地点という証明になりはしないだろうか。
重ねて重要性を証明するのなら、人間の四感は視界、音、振動、臭いすべて空間を知覚できる。それは距離、場所というのが、生きていくために不可欠で、一部が欠落しても、あるいは全てを動員してでも知る必要があるからだ。
じゃあ Web のはなしをする。
サイトマップ、コンテンツリスト、この際名称は何でもかまいやしない。どういったコンテンツがどれだけあり、それがどういった分類をされるのか、もしくは分類されないのか、という定義は、これをなしに Web サイトは作れないわけで、誰でもまず当たり前にこれを作成するものとする（何を作るのか分からないのに見積もりはできない）。
案外、 URI というのは軽視されがちで、そもそもそれがどういった意味をもっているのか、ということを考えるデザイナーは少ない。
そこで、最初にクドクドと説明した場所という概念がでてくる。
サイトマップには場所がない。
ただ、何があるのかが書いてあるだけだ。
どこにあるのか、それは関係性のデザインを具体化することでもある。分類に基づく場所というのを与えることは、それまでなかったものに名前を付けるのに似ている。
名前の無いものは言葉にできない。概念の伝達に不具合が生じ、むやみやたらと時間を喰う。名前は識別子で、共通の概念を喚起する記号でもある。名前があれば愛情がわくし、もし飼い犬に名前をつけないのであれば、そこに飼い犬とその他の犬という境界は存在しなくなる。
絶対的な情報というのは存在しない。もし存在してもそれの価値はたかが知れている。情報は繋がることで価値が生まれる。そしてそこには関係性というのが不可欠なものになる。
関係性のデザインはデザインそのものでもあるのだから、これを放棄してしまっては良いデザインはできないと思う。
もちろん、メンテナンスビリティ、クオリティという面からいっても、これを欠くと低下するのはサイトを一つか二つつくれば、誰でも実感する。
]]>
