POLAR BEAR BLOG: 良いFAQを作るには？
How-To モノが続いてしまいますが、これなんかも参考になる部分が多いのでは。Usabilitynews.com に、「良いFAQを作るには」というエントリが掲載されていました。FAQ に限らず、分かりやすい回答を作る上で参考になりそうです： ■ Caroline's Corner: How to write good FAQs (Usabilitynews.com) FAQ の良し悪しを分けるポイントが7つ列挙されています。それぞれ抜粋して訳してみると…… 1. 「簡単に答えられる質問（Easily Answered Questions, EAQ）」ではなく、文字通り「よく聞かれる質問（FAQ）」に答えること 簡単に答えられる質問ばかり選んで回答を書いていないか？本当によく聞かれる質問に答えること。また「ユーザーがする質問」ではなく「関係者がする質問」を選んでいないか注意すること。 2
多くのユーザーは一度に1本しかジュースを買わない ― ＠IT
ユーザビリティのヒント（1） 多くのユーザーは 一度に1本しかジュースを買わない 「自動販売機での不要な動作から考える」 ソシオメディア 上野 学 2006/6/2 Webアプリケーションのユーザーインターフェイスデザインに役立つさまざまなTips集。自動販売機でジュースを買うときの不要な動作から考える。（編集部） 今回からはWebアプリケーションのユーザーインターフェイスの続編の「Tips編」として、ウェブアプリケーションのユーザーインターフェイスをデザインするうえで役立つさまざまなヒントを、少し細かな視点から具体的に見ていきます。 複雑な構成物を作り上げるには、基本となるコンセプトやアーキテクチャといった抽象度の高い部分から考えていくトップダウン式のアプローチと、構成要素の細部から考えていくボトムアップ式のアプローチの両方が必要になりますが、前回までの経験則編はどちらかといえばトップダ
大切な文字を赤で印刷するのはやめて欲しいバトン
世の中には、「一度こうするのが常識」と決まってしまうと、それが明らかに間違っていることであっても、疑問にも思わずに続けてしまう人が沢山いる。 その良い例が、左の写真のような「屋外にある機器の注意書きのうち、大切な文字を赤で印刷する」という習慣である。確かに印刷したばかりの時の赤い文字は目立つので良いのだが、赤のインクで印刷された文字は（特に日光に当たる場所に置かれていると）時間とともに薄くなり、しまいには読めなくなってしまうことは誰もが色々なところで見かけて知っているはずである。 にも関わらず、相変わらず「大切な文字を赤で印刷する」習慣をストップしてくれないのが私としては我慢ができないのだ。 そこでこのブログを通じて、この悪習を無くすためのキャンペーンの呼びかけをすることにした。題して、「大切な文字を赤で印刷するのはやめて欲しいバトン」である。 「そうそう、私も見たことがある」、「私はこん
分裂勘違い君劇場 - 見た瞬間に使い方の分かるユーザインタフェース
「初心者にわかりやすいGUI」については、この記事のid:naoya氏の気持ちは、分かる気がします。 まず、プロのGUIデザイナーと実プロダクトの仕様について議論すると、ほとんど必ずと言っていいほど議題に上がるのが、「とっつきやすや」と「機能性」のトレードオフ。 よく、回すべきなのかスライドべきさせるのか、押すんだか引くんだかよく分からないドアというのがある。ドアのどちら側を押すべきなのかも分かりにくいことも多い。それは、ユーザインタフェースが、self explanatory(自己説明的)じゃないからだ。これは、よくユーザインタフェースの設計ミスの事例としてやり玉にあげられるんだけど、ぼくは、それはそんなに単純な話じゃないと思うのだ。 たとえば、丸い取っ手のあるドアは、見た瞬間、「ああ、これはドアノブを回して引くんだな」ということが、直感的に分かる。つまり、そのドアノブは、「機能」を提供
没入感の中断 : 小野和俊のブログ
1976年生まれ。1999年慶應義塾大学環境情報学部卒業後、同年サン・マイクロシステムズ株式会社に入社。入社後まもなく米国 Sun Microsystems, Inc での開発を経験し、2000年より株式会社アプレッソ代表取締役に就任、データ連携ミドルウェア DataSpider を開発する。2002年には DataSpider が SOFTIC ソフトウェア・プロダクト・オブ・ザ・イヤーを受賞。2004年度未踏ソフトウェア創造事業 Galapagos プロジェクト共同開発者。2007年〜2010年日経ソフトウェア巻頭連載「小野和俊のプログラマ独立独歩」執筆。2008年〜2011年九州大学大学院「高度ICTリーダーシップ特論」非常勤講師。2013年よりセゾン情報システムズ HULFT事業CTO、2014年 CTO、2015年 取締役 CTO、2016年 常務取締役 CTOを務め、2019年
"使いやすさ"への取り組み / 「使いやすさ」の考え方 掲載リスト | Ricoh Japan
1969年 （株）リコー入社 OA器機のテザイン、システム製品のSEを担当 1985年 社内ユーザーインターフェースの開発グループ設立に参加 電子ファイリングシステム、デジタルコピー機のインターフェースデザイン及びユーザビリティー評価の実施 各種のソフトウエア製品のインターフェースデザイン及びユーザビリティー評価等に携わる 1997年 （株）インターソフト設立 システム製品の開発現場でのユーザーインターフェースソフトウエア開発の経験を生かして、製品のユーザビリティーの評価とその結果をもとにしたユーザーインターフェースのデザイン・設計を行なっている ヒューマンインタフェース学会会員 人間工学会アーゴデザイン部会幹事
最速インターフェース研究会 :: 全てのWeb開発者必見 : remember the milk のサインアップフォーム
ライブドアの次世代テクノロジーセミナーの後の二次会の後のSledge勉強会で発表したネタ。 http://www.rememberthemilk.com/signup/ Ajaxを使ったTODO管理やらリマインダサービスらしいのですが、これのサインアップフォームがとてもよく出来ています。苗字と名前から自動でアカウント名を補完してくれたり、それをサーバーに問い合わせてそのアカウントが取得できるかどうかを確認してくれたりします。 肝心のサービスの中身は使いやすいのかどうか良くわかんないというか、正直微妙な感じなんですが、一度しか通過しないサインアップフォームを作りこむ心意気が良いですね。 別に必見ってほどでもないか。でも知ってる人がいなかったのでブログに書いておくことにします。 ユーザーを「手厚く」サポートする UI 最速インターフェース研究会さんの 全てのWeb開発者必見 : remembe
ファイル名はなくてもいいかもしれない - モジログ
言語ゲーム - 無名ファイルシステム http://d.hatena.ne.jp/propella/20050822/p2 ＜無名のファイルシステムを考える。無名とは呼んで字の如くファイルに名前がついてない事である。私達はファイルには必ずファイル名がついている物と考えているが、ファイル名には欠点がある。だからファイル名は無いほうが良い。少なくともファイル名が無くとも動作するシステムを設計するべきだという主張＞。 ＜簡単な話ファイルをメモリのように扱うという事だ。ファイルは無名であるべきである＞。 たしかに、そうかもしれない。 わたしたちはもうURLに慣れている。 いまではURLのほとんどは自動的に生成されているが、それで誰も困らない。 とにかく一意的にページやファイルを識別できればよく、自動生成でも構わない。 多くのブログツールではエントリのIDを自動生成するが、それと同じでいい。 ファイ
ビル・ゲイツの家のトイレは流そうとすると「本当に流しますか？」と警告してくる
今回のみずほ証券による株の誤注文事件は、１株を６１万円で売るところを、オペレーターが誤って「６１万株を１円で」と誤入力してしまったのが原因だが、その際に端末には市場価格との隔たりを示す警告が表示されたにもかかわらず、オペレーターが「（警告が）よく出るので慣れの中で結果的に無視してしまった」という点が注目に値する。 以前にも、「事故防止の難しさ」というエントリーで触れたことがあるが、「不必要な警告をしょっちゅう見ているとそれに慣れてしまい、本当に対応が必要な時にも無視してしまう」というのは人間の性である。この手のミスをした人を一方的に非難したり、「これはヒューマン・エラーでした、今後はこのようなことを繰り返さないように注意します」と謝るのは簡単だが、それでは根本的な事故防止はできない。 「不要な警告」と言えば、パソコンがその代表選手。ファイルを消去した時の「本当に消去したいですか？」という警
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OKボタンの位置はどこが適切?