ユビキタスとは何か―情報・技術・人間 (岩波新書 新赤版 1080)
デザインとは資産であり、消耗品ではないwebに限らずプロダクトでも言えることだが、すばらしい性能を持っていたとしても
デザインは先に決めてしまおう確かに練りに練った企画でもそれにデザインを当ててみると、
Webサイトプランニングブック (WSe Books # 6) (WSe Books # 6)
KJ法のようにキーワードを掛け合わせることを繰り返すといつのまにかカオスが一言に集約するちょっと強引な感も否めないが、ただ情報を溜めていくだけではアイデアは生まれない。
「答えは相手の中にある」という信念に対しては共感できる。
「自分の作りたいものを作るのではなく、相手のビジョンをカタチにするのが仕事だ」
クライアントの代弁者であるのと同時にユーザー側の代理人でもある
対象サイト : | 楽天市場 |
被験者 : | オンラインショッピング経験のある20代~30代男女、各3名 |
タスク : | バレンタインデーもしくはホワイトデーのギフトを楽天市場にて購入する |
予算 : | 3000円程度 |
マイナスを限りなくゼロに近づけるユーザビリティと、というのがあるが、現状のPCやブラウザのインターフェースではユーザビリティを確実に抑えつつ
ゼロから出発してプラスを積み上げていくユーティリティとの組み合わせ
こんなデザインが使いやすさを生む―商品開発のためのユーザビリティ評価
総務省は、利用者に対するサービス向上の観点から、次世代サービスに対応した端末から、ICカードの他社利用制限を原則禁止する方針を固めている。このため、利用者は気に入った端末とサービスの組み合わせを自由に選べるようになる。携帯電話会社はより格安な料金プランなどを用意して顧客をつなぎ留める必要が出てくる。
[訂正 1] 脳直結となってもUIデザインが不要になるって訳ではなく、むしろハードウェアのUIよりソフトウェアのUIが一層重要になってくるということですね。
最初は脳からディスプレイ内に出力する形だろうけど、最終的には脳内で完結。つまりUIが脳内に入り込むという・・・。以上、たわいもない妄想でした。(08/04/03)
【用語解説】第4世代(4G)移動通信システム
1980年代の第1世代携帯電話(アナログ式)、90年代の第2世代(デジタル化)、2000年代に普及した第3世代(高速データ通信を実現)に続き、超高速通信を可能にする技術規格。
通信速度は最大毎秒1ギガビット、高速移動中も100メガビットが目標で、日米欧の主要通信事業者や機器メーカーが開発競争を展開している。
写真のセンスが全く無いので、フィルム代を気にせずバシバシ撮れるデジタルカメラでないと厳しいんだな。
そんなところ、デジカメでしかも4,680円という「ビスタクエスト VQ1005」っていうトイカメラを発見、
マッハでカートに入れました。
作りはもう貧弱で完全にオモチャ。しかも電池はすぐ無くなる。
でも気軽に持てて、フィルムと同じようにその場では写真を確認できないことも手伝ってワクワク感が高まります。
思いっきり顔が切れてるけど、ご愛嬌ということで・・・。
これからの写真ライフが楽しみです。
JavaScriptのみで稼動するため、サーバサイド処理が不要でサーバのリソースを節約できます。
また、郵便番号を入力すると即、住所が自動入力される、ユーザーにもサーバーにも優しい優れものです。
ただ、残念なところは、
全角数字に対応していない
全角と半角の区別がつかないユーザーは多いのです・・・。
ブラウザが記憶している郵便番号をセレクトすると住所が自動入力されない
あくまでも手入力に限るようで・・・。
これらがクリアできれば更に使い勝手の良いフォームになることでしょう。
]]>
そもそも、HTML仕様書の定義があいまいなのがいけなくて、
ユニークな要素には名前(id)を与え、それらが属するカテゴリには種名(class)を与えるという考え方は矛盾しています。
例えば「山田 太郎」だって、
「山田」もしくは「太郎」がカテゴリにあたり、「山田 太郎」がユニークかというと一概にそうとも言えないです。
なぜなら全国に「山田 太郎」という名前は何人もおり、
名前という情報だけで特定の人物を指すことは出来ないのですから。
強いて言うなら、下記が一番考え方としては近いのかなと思います。
実際のところ自分はほぼclassで統一しています。
たまにjavascript絡みやページ内リンクの為にidを振ることはありますが、
それでもやはり同タグにclassを入れスタイルもclassに対して当てています。
オールclassという書き方が良いのかどうかは議論が分かれるところだと思うのですが、
正直、idにするかclassにするかで悩む位ならclassでいいんじゃね?というのが僕のスタンスです。
コーディングするにあたり大事なポイントはそこじゃないです。
例:<br class="clear" />とか<div class="cl"></div>などなど
その時は良くても、レイアウト変更で不要になったときに、このゴミはどうするの?って話です。
シラミ潰しに消す? まるでエベレストのゴミだ。
上記と同じくレイアウト変更で不要になったときにどうするんだろう?
そもそも「clearfix」ってカテゴリあるはずないし・・・。
残念ながらマークアップの意味がわかっていないままコーディングしちゃってるのでしょう。
偉そうなこと言ってるけど、自分も最初の頃は上記のような過ちを犯しまくってました。
試行錯誤でやっているうちにある結論に達しました。
汚いHTMLは論外ですが、
美しいHTMLを書くことが一番大事かというとそうじゃないと思います。(美しいに越したことは無いのですが)
マークアップは生き物です。
それぞれコードを書く人の個性が出るものだと思ってます。
したがって、厳密に正しい書き方は無いのですが、
最低限のルールを守るためにマークアップの意味を理解することが大事です。
一番重要なのは、
この先何度もリニューアルを繰り返しても、手間をかけず再利用できるマークアップが究極だと思います。
代表的な例が、text-indent にマイナス値を入れてテキストをどっかに飛ばし(隠し)、
background にオンとオフをひとまとめにしたボタン画像を埋め込み、:hover でスライドさせるテク。
Dave Woods - HTML, CSS, Web Design - [サンプル]
実装が簡単なうえ、オンとオフ2つのボタンが一つの画像ファイルになっているのでサーバへのアクセス負荷軽減等のメリットがあります。
ブラウザ設定で画像を非表示にした状態で見ると、画像どころかテキストさえも表示されません。
もしこれがサイトにおける重要なメニューだとしたら、最悪です。
<img>をHTMLに直に貼り付けていれば、画像非表示でもAltに入っているテキストが表示されます。
画像非表示だと、
こんな風にちゃんとテキストが表示されます。
でもこれだけだとマウスオーバー時のアクションがありません。
<li>タグの background にオフ画像を入れ、マウスオーバー時にHTML上にある<img>を visibility:hidden; で見えなくします。
そうすると、liにあるオフ画像が現れるというカラクリ。
でもIE6の場合、:hover は<a>要素以外は未対応の為、<img>が隠れてくれません。
つまり、マウスオーバー時のアクションがありません。
IE6は:hover 時の<a>の画像なら表示できるので、:hover のbackground にもオフ画像を入れます。
画像非表示だと、
完璧です。
オフ画像は:hover だけ入れれば良いじゃん?<li>にも必要なの?という疑問を持たれた方もいるかも知れません。
何故、<li>にも必要かというと、:hover の場合マウスオーバーした瞬間に画像を読み込んでいるので
一瞬ボタンが消えてしまいます。
<li>に入れておけば画像は既に読み込んであるのでスムーズにオンオフが出来るということです。
日本ほど 「 朱 」 の似合う国はない。
「 朱 」 は日本のためにあると言っても過言ではない、と思う。
#e04060 | #f06080 | #e02040 | #c02020 | #a06040 |
#e04040 | #804020 | #c08060 | #e06060 | #e0a0a0 |