Eye-tracking studies: more than meets the eyeHey—we've moved. Visit The Keyword for all the latest news and stories from Google
サイト作りに使えるインターフェースのパターンが満載！『UI Patterns』 - IDEA*IDEA ～ 百式管理人のライフハックブログ ～
ドットインストール代表のライフハックブログ
魚眼式タブ FishEyeTabs | 秋元@サイボウズラボ・プログラマー・ブログ
via del.icio.us/popular FishEyeTabsは、Firefoxのちょっとしたアドオンで、複数のタブを開いているときに、マウスが上に乗った注目しているタブの幅を大きくして、そのタブのタイトルを見やすくしてくれるというもの。 魚の眼が見るように、たくさんタブがあっても広角で全体を見つつ、注目してるところを広いあげられる、というインタフェースということか。 考えてみたらMacOSXの下にあるやつがそうだった。あれみたいな効果が、Firefoxのタブで得られるということ。 アドオンのページでは、2002年に提案されているFisheye式リストボックスというのも紹介されていた。 こちらは、リストの要素が大量にあったときに、スクロールバーを出すんじゃなくてこの魚眼式リストにするのはどうだろう、というUIの提案。 上がFisheyeで、下が通常のリストボックス。デモページでは実
UI：アプリケーションの世界を描くこと: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 すこし前に受けたユーザー中心設計エンジニアリングの講義の中で紹介されていた事例がずっと気になっていたんだけど、うまくアウトプットできずにここで書かずに寝かせていました。 実際のモデルと想起されたモデルの相違あるモバイル系のアプリケーションで、実際のシステムモデルとユーザーが頭の中で想起した概念モデルがまったく違ったものになってしまったために、致命的なユーザビリティの問題（使えない！）が発生したそうです。 ユーザーが頭に思い浮かんだ概念とおりに、操作を進めていくと、設定が不完全で本来達成すべき目標が実行できないため、「なんだこのシステム使えない！」と思ってしまい、たくさんのクレームが発生し、サービス提供側が想定していたようには利用者も増えなかったということです。 なぜ実際のシ
エレベータのUI
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45685 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
画面レイアウトを考える その１モニターサイズとwebブラウザ可視領域について
実際にサイトをレイアウトする手始めの段階で必ず考えておかなければならないのが、ターゲットとするユーザーのサイト利用環境、ターゲットモニターサイズである。サイトを閲覧するために一般ユーザーが使っているPCのモニター表示解像度は、人によって大きく異なる。現在標準と言われている表示解像度は、XGA（1024×768ドット）だ。現在の標準的なPCがこの解像度を使っており、比較的古いタイプのPCでもこの程度のサイズをカバーしている。古いラップトップパソコンを使っているユーザーであれば表示解像度はSVGAの可能性があるが、PCの最小表示サイズVGAモード同様、新型のOSが対応するPCではあまり日常的に使われていないと考えてよい。また現在ではSXGA（1280×1024ドット）の解像度も優勢で、WindowsXPやMacOS X世代のOS対応機はこの環境に対応するものがほとんどだ（図１）。 モニターサイ
CNET Japan Blog - 中島聡・ネット時代のデジタルライフスタイル：ユーザー・エクスペリエンスとパーベイシブ・アプリケーションの世界
では、「さまざまなデバイスをネットワークを通じて有機的に結合させ、トータルで見たときのユーザー・エクスペリエンスを向上させる」とは具体的にどんなことなのだろうか？ ヒントは私達のまわりにたくさんある。「必要は発明の母」とは良く言ったもので、私たちがさまざまなデジタル機器を使う上で、ちょっとでも不便だな、と思うものをメモしておくだけで良いのだ。 ・子供を連れてディズニーランドに来た夫婦。デジカメを持った父親が子供の楽しんでいる姿を撮影する。家に帰ってから撮影した写真をパソコンに移す。夫の実家にはパソコンがあるので、メールで送れば良いのだが、妻の実家にはパソコンがないので、プリントしたものを次の週末に持って行くことにする。 ・Beatlesが大好きな音楽ファン。Beatlesの曲ならば何でも持っており、全ての曲は彼のiPodに入っている。その彼が週末に友人の車でスキー旅行に行くことになる。ドラ
「みんなの意見」を生かしたユーザー導線
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 これまでWebサイトのユーザー導線の設計は、Webサイトを構築する側が決めるのが当然のように思われていたと思う。 でも、今後はその考え方ってかならずしも「当然」ではないはずだ。 「情報デザインおよび組織デザインにおけるツリー構造とリンク構造」では、 ファイルをベースに考える還元主義的発想から、ユーザー行動をベースにとらえるネットワーク的発想に切り替えていかないと、この膨大な情報を処理可能なWebサイトの設計なんてできないんじゃないかと思うのだ。 なんて書いたが、この発想をもう一歩進めると、情報間のユーザー導線を決めるナビゲーション＝リンクの設定をそのものに、ユーザーの行動結果や意見を反映する機会をもっと増やしたら、どうかと思うのだ。 とはいえ、何もこの考え方はとりたてて新し
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
エンジニアがダメなUIデザインをする原因
ことビジュアルデザインに関しての経験論としては、 ・エンジニアは画面のオブジェクトや文字の単位で画面を見る。 ・デザイナーはピクセル単位で画面を見る。 そもそも見ている解像度が違う。 エンジニアは機能を見る。デザイナーは間隔を見る・・・って言ったら言い過ぎ？ そもそもインフォメーションデザイン、インタラクションデザイン、ビジュアルデザイン、システムデザインは、すべて別個の職能だと思います。このうち、どの範囲の能力を保有してるかで、戦士にも魔法使いにもなれるんじゃないでしょうか。まぁ全部を十分に持ってる人は滅多に見ませんけどね。そういう人は、yugoさんのような世界的なアーティストとして活躍してることでしょう。 Ajaxを作る場合は、いわゆる「エンジニア」と呼ばれる人が、システムデザインはもちろん、インフォメーションデザインとインタラクションデザインのかなりの部分を担当することにならざるを得
カーソル位置のセルの上端と横端をハイライトする JavaScript
■ カーソル位置のセルの上端と横端をハイライトする JavaScript 好評の、読み込ませるだけで動く JavaScript シリーズの5段目くらいです。このシリーズもたまってきたので、そのうちまとめます。 Excel とかの表計算ソフトって選択しているセルの列番号や行番号がハイライトされたりしてますよね？table タグ上であれと同じものを実現する JavaScript を書いてみました。 こんなようなテーブルを作らなくちゃいけない事になりそうなんだけど…。 実際には15×20くらいはあるので、チェックを入れる時にすごく使い辛そうですよね。なので、カーソルの位置がわかりやすくなるようにハイライト出来たら便利だろうと思ったんです。 実際の動作サンプル rowspan とか colspan を使って複雑にしていると、上端とか横端の位置を取得するのがやたらと面倒になってくるので、画面上のセル
fladdict.net blog: 「本当に素晴らしいデザイン」とは、PICASAの変なスクロールバーみたいなものを言う
お気に入り巡回先の、羨望は無知の「なぜ「デザイン」という行為、「デザイナー」という職業は誤解されるのか」や、分裂勘違い君劇場の「エンジニアの方が優れたユーザインタフェースデザインができる理由」、F's Garageの「エンジニアがダメなUIデザインをする原因」 のあたりのデザイン論が、あんまりデザインと縁のない人にデザインをわかりやすく説明してて面白い。面白いのだけどちょっと抽象的なんで、具体例の話とか書いてみるテスト。 最近、これらのエントリーで言及されるようなよいデザインを身をもって体験をした。それは画像管理ソフトPICASAのヘンテコなスクロールバー。 今まで気付かなかったけど、あのヘンなスクロールバーは単なるアヴァンギャルドやオシャレじゃあなかった。実は合理性に裏打ちされた素晴らしく美しいデザインだということに気付いた。 まずPICASAを知らない人に説明すると、このソフトのスクロ
分裂勘違い君劇場 - エンジニアがUIデザインしたがる本当の理由
ハイライトピックアップ Web2.0を引き起こしているのと同じ時代の潮流が、エンジニアの地位の低下を引き起し、エンジニアがUIデザインをしたがる動機を創り出している。 Googleは、「エンジニアの会社」という皮をかぶった「企画・マーケティング・デザイン」の会社である。 エンジニアよりデザイン能力の低いダメデザイナーがうじゃうじゃでてくる構造。 優秀な人ならデザインスキルがなくてもいいデザインができるのは幻想。現実には、デザインスキルの差は容易には超えられない壁。 デザイナーに必要な技術的知識とエンジニアの技術的知識は別物なので、エンジニアの技術力はデザインをする上でそれほど強みにならない。したがって、技術力とデザイン力を兼ね備えた優秀なデザイナーはエンジニアとデザイナーのハイブリッドではない。 一人の人間がUIのデザインと実装を両方やると二兎を追うものになってUIの質が低下する。二兎を追
分裂勘違い君劇場 - エンジニアの方が優れたユーザインタフェースデザインができる理由
それから、これは個人的な意見ですが、プログラマはコンピューターの扱いになれているから、そうでない人が使うためのインタフェースを設計することができない、みたいな話をときどき耳にしますが、僕はそれに懐疑的です。インタフェースをうまく設計できない人というのはプログラマに限った話じゃない。それは「プログラマは営業ができない」と乱暴にまとめてしまうのと同じようなこと。 たぶん、プログラムができるかできないかということと、インタフェースをうまく設計できるかできないかというのはあんまり相関がないように思います。むしろコンピュータの世界では、プログラマは頭のなかで思い描いたインタフェースを実現する手段を最も良く知っている部類の人で、インタフェースを作るセンスさえ持ち得れば、それ作るのにもっとも適した人たちなんじゃないかと思います。 知り合いの会社では、半期ごとだかクオーターごとだかに、その期に、もっとも優
UIがゲームのようにいかない理由 - 等速ナブラ
直也さんのエントリ。 ゲームのインタフェース - naoyaのはてなダイアリーウェブのインタフェースとかはかなりいろんなところで制限があるので似たようなものになりやすいというか、オリジナリティがそれほど求められないことも多いわけですが、ゲームのインタフェースっていうのはゲームが違えばその感じもだいぶ違ってて、考える方は大変だし相当の創造性があるなあといつも思います。 ボクは一応両方とも開発現場に居た経験があるので僭越ながら理由をぼちぼちと。まず、作り手側からすると全然作り込み甲斐がある。ゲームの方が。何故かというとまずライブラリに圧倒的な差があって、方やスタイルシートやJavaScriptのなけなしの関数を使ってなんとか魅せるようにするしかないのだけど、ゲームとなると充実したグラフィックライブラリがあるわけで。それに、かなりハードに近いレベルでのコーディングも可能。 今でこそ高級言語を使用
インタフェースの話 - naoyaのはてなダイアリー
一つ前のインタフェースの話。いろいろフィードバックをいただきました。ありがとうございます。 >
分裂勘違い君劇場 - 見た瞬間に使い方の分かるユーザインタフェース
「初心者にわかりやすいGUI」については、この記事のid:naoya氏の気持ちは、分かる気がします。 まず、プロのGUIデザイナーと実プロダクトの仕様について議論すると、ほとんど必ずと言っていいほど議題に上がるのが、「とっつきやすや」と「機能性」のトレードオフ。 よく、回すべきなのかスライドべきさせるのか、押すんだか引くんだかよく分からないドアというのがある。ドアのどちら側を押すべきなのかも分かりにくいことも多い。それは、ユーザインタフェースが、self explanatory(自己説明的)じゃないからだ。これは、よくユーザインタフェースの設計ミスの事例としてやり玉にあげられるんだけど、ぼくは、それはそんなに単純な話じゃないと思うのだ。 たとえば、丸い取っ手のあるドアは、見た瞬間、「ああ、これはドアノブを回して引くんだな」ということが、直感的に分かる。つまり、そのドアノブは、「機能」を提供
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
amazwalk
WINDOWSアプリケーションを作っているのですが、もっとセンスの良い配色にしたいので、配色見本がいくつか載っているページを教えてください。…