タグ

Usabilityに関するthunderpoolのブックマーク (6)

  • @IT:入力情報を預かる責任を果たせる画面デザインとは?

    Webアプリケーションのユーザーインターフェイス[5] 入力情報を預かる責任を果たせる画面デザインとは? 「ユーザーを尊重するということ」 ソシオメディア 上野 学 2005/10/19 前回の「お金を下ろせないATMの画面デザインを考える」では、そもそもシステムがユーザーの基的な目的を達成させるものでなければ、いくら表層的なデザインを最適化しても意味がないのだというお話をしました。ユーザーの基的な目的を達成させるためには、いうまでもありませんが、まずユーザーの要求をよく分析する必要があります。そしてそこから機能要件を決定し、画面の内容や画面遷移を考えていきます。使いやすいシステムを作り上げるためには、こういったユーザーインターフェイスやインタラクションのデザインをできるだけプロジェクトの早い段階で行う必要があるという話もしてきました。 では実際に画面の内容や画面遷移を決定していくうえ

  • Alertbox: 2005年 ウェブ・デザインの間違いトップ10(2005年10月3日)

    2005年、ユーザをうんざりさせてきたWebデザインの間違いをリストアップしてみると、古くから言われているものがランクイン。悪さをし続けていることがわかった。 Top Ten Web Design Mistakes of 2005 by Jakob Nielsen on October 3, 2005 Webデザインの間違いをリストアップするにあたり、今年は趣向を凝らしてみることにした。私が発行しているニュースレターの読者にお願いして、今年、もっとも腹立たしいと思ったユーザビリティ上の問題点を投票してもらったのだ。 読者の参加によって、ユーザテストでは気付かなかった多くの課題が浮き彫りになるだろうと思っていたが、そうはならなかった。30位までにランクインした問題点は、ユーザビリティガイドラインの中で指摘済みのものばかりだったのだ。今年のトップ10を読んで、“聞き覚えがあるぞ!”と思われる方

    Alertbox: 2005年 ウェブ・デザインの間違いトップ10(2005年10月3日)
  • ユーザビリティテストの時間配分

    テスト時間の40%が、不必要なことに使われ、無駄にされている。ユーザが対象インタフェースのデザインを使う様子を観察することに集中したほうが、遙かによい。 Time Budgets for Usability Sessions by Jakob Nielsen on September 12, 2005 ほとんどのデザインチームは、ユーザの実際行動を観察する時間を、十分取っていない。もちろんほとんどの企業がユーザテストを全く実施していないのが実状だが、実施している企業でも、行動を観察する時間を十分取っていないのだ。 理想は、1週間あたり1日(たとえば毎水曜日)を4人のユーザでテストを行う「ユーザテストの日」とすることだ。もちろん毎回新しいユーザを使う必要がある。各テストで新しいユーザを使うことは、テストユーザのリクルートにおけるガイドラインの1つだ。(実際には7つのガイドラインが、この話題に

    ユーザビリティテストの時間配分
  • 使いにくい業務システムが生まれる理由

    「これからは,現場のユーザーのことを考えた使い勝手の高いシステムを作れないITベンダーさんには,発注しません」。ソニー生命保険は最近,取引先のITベンダーに対してこんな方針を打ち出した。 目的は,営業支援システムなど基幹業務システムの刷新を格化するに当たって,使い勝手の高いシステムを設計開発できる体制を整えるためである。そのため今年1月までに,業務システムの使い勝手(ユーザビリティ)とは何かを定義したうえで,ユーザー・インタフェースの設計プロセスや画面一つひとつのデザイン方法などに関する社内標準を策定。それらに準拠することを,取引先のITベンダーにも求め始めたというわけだ。 ユーザー・インタフェース設計の責任者となった長尾和洋 営業企画部営業情報支援部web支援課主事は,元営業担当者としての経験を踏まえてこう語る。「システムのちょっとした使い勝手の悪さも,それを日々使う現場のユーザーに

    使いにくい業務システムが生まれる理由
  • submit ボタン disable 技の罠 - naoyaのはてなダイアリー

    昨日のonsubmit で submit ボタンを disable にしてユーザビリティを良くするにはちょっとした罠があって、それに気付かずに使うとはまってしまうかもしれないので、それもちょっと書いておく、というか今日僕自身がはまったわけだが。 罠というのは、type="submit" な input 要素、つまりは submit ボタンを onsubmit ハンドラで disable するまでは良いのですが、このとき <input type="submit" name="foo" value="bar">としていて、foo=bar という値が渡ってくることを期待し、それを内部の処理に使っていると嫌な目に逢う、という話です。先のやり方では input 要素が disable になって GET なり POST なりされるので、押したボタンに対応するパラメータが渡ってこない、というわけです。一

    submit ボタン disable 技の罠 - naoyaのはてなダイアリー
    thunderpool
    thunderpool 2005/08/05
    disableの話、続き。後で試す。
  • naoyaのはてなダイアリー - onsubmit で submit ボタンを disable にしてユーザビリティを良くする

    先の Yahoo! Shopping のアプリケーションで、今度ちょっとやってみようと思ってたことを実装してみた。 http://bloghackers.net/~naoya/ys/app.cgi ボタンを押したときに、そのボタンが disable になります。この方法を使うとボタンが押されて次の処理に入ろうとしているというのが直感的に分かるのと、二重送信防止にもなるということでユーザビリティが改善できます。 仕掛けはすごく簡単で、form の onsubmit ハンドラに、その form に紐づく submit ボタンを disable になるような JavaScript を登録しておくだけ。 function disableSubmit(form) { var elements = form.elements; for (var i = 0; i < elements.length;

    naoyaのはてなダイアリー - onsubmit で submit ボタンを disable にしてユーザビリティを良くする
  • 1