タグ

uiに関するakishin999のブックマーク (472)

  • エラーメッセージはフォームのどこに表示するべきか

    UX Movementの著者および設立者です。ユーザー体験のデザインスキルの開発を手助けしてよりユーザーフレンドリーな世界のために、このブログを創設しました。 フォームのどこにエラーメッセージを配置していますか? ユーザーの期待する場所にエラーメッセージが置かれていないと、ユーザーはフォーム入力を完了できなくなってしまうかもしれません。 フォーム入力を間違えたら、ユーザーはそれを修正して送信し直すために、なにが間違っていたのかを理解する必要があります。フォームを完了しようと思っていたとしても、それがあまりにも大変であればユーザーは心変わりしてしまうでしょう。 フォームの上か、フィールドのインラインか エラーメッセージの配置場所でもっとも一般的なのは、「フォームの上」と、「エラーのあるフィールドのインライン」という2箇所です。どちらの配置場所が、ユーザーにとってより直感的でしょうか? 調査に

    エラーメッセージはフォームのどこに表示するべきか
  • 邪悪なUIチェックポイント - その先へ

    ハロー、@seto_hiです。 北海道で避暑をしています。 アプリ開発をしていると様々なコンバージョン率がKPIになることは多いですが、誠実さを欠いたUIを作ると数字がよく伸びることが稀によくあります。 そういったものは一時的な利益には繋がりますが、長期的な利益には繋がらないと考えています。 自分が今後そういったUIを作らないための予防線としてこの記事を書きます。 不利益の排除 ・不利益な動線を奥深くに隠す ・ユーザーが設定を変更する手間を増やす ・「メールマガジンの解除にはメッセージを送ってください」 ・「メールマガジンの解除にはログインが必要です」 ・過度に警告を表示する ・「この設定をOFFにするとアプリが正常に動作しなくなる可能性があります」 ・「当にOFFにしてよろしいですか」 ・不利益な動線を目立たなくする ・不利益な動線のシグニファイアを消す ・スマートフォンならスクロール

    邪悪なUIチェックポイント - その先へ
  • 某RPGっぽいUIをCSSとHTMLだけでつくってみたよ - Qiita

    背景 CSSだけで色々出来ることが分かってきたので、少し作ってみたよ。 *PCChromeでしか確認してないよ! 実装 CheckBoxで状態変化 CheckBoxがチェックされたときだけ状態を変化させる感じ。 下記のような実装で対象となる要素の状態を変えられる <input id="s1" type="radio" name="sel"> <label class="sel" for="s1" id="sl1">こうげき</label> .nesttarget{ /* ~~省略~~ */ display:none;/* 通常時は表示を消しておく */ } #s1:checked ~ .nesttarget{ display:block;/* CheckBoxがcheckedに変化した場合に表示 */ }

    某RPGっぽいUIをCSSとHTMLだけでつくってみたよ - Qiita
  • Vue CLI UIが想像以上に便利だった話 - Qiita

    概要 最近、vue-cliがバージョンアップしていて、ふーんとか思いながら流してたんですが、vue-cli uiという機能があることを教えてもらい改めて調べて動かしたら結構感動してしまったので、記事にしてみました。cli-uiどうなん?って思った方のお役に立てていただければと思います。 プロジェクトを始める いつものCLI とりあえずcliをグローバルインストール!!

    Vue CLI UIが想像以上に便利だった話 - Qiita
  • 人はなぜ「分かりやすいデザイン」でも失敗するのか|Tsutomu Sogitani

    これは私が最近よく訪問する日橋駅直結の商業ビル、東京日橋ビル内のエレベーターのボタンです。 唐突に質問ですが、このボタンで操作ミスを起こすポイントがあるとすれば、それがどこだか分かりますか? 説明が必要と思いますが、このビルは7Fがオフィスロビーになっています。駅直結のB1と1Fからは7Fまで直通するシャトルエレベーターがあり、全員7Fで一度降り、セキュリティチェックをし、23Fより上にあるオフィスフロアに入ります。そのオフィスロビーとオフィスフロアを行き来するためのエレベーターのボタンがこれです。 ボタンが23Fから30Fまでしかなくて、下に大きく7Fのボタンがあるのは、そういったビルの構造からです。 私と同行したディレクター(26歳)は、打ち合わせが終わってオフィスフロアからオフィスロビーに帰る際に、操作ミスをしました。それも1度だけでありません。次の打ち合わせの帰りにもまったく同

    人はなぜ「分かりやすいデザイン」でも失敗するのか|Tsutomu Sogitani
  • 画面遷移図の作成方法ついてのまとめ - Qiita

    はじめに この記事は、アプリケーション開発におけるUI設計の、画面遷移図について個人的に考察したものです。画面遷移図を作る上で、現状どのような選択肢があるかをまとめています。正直調べ足りないところも多々ありますので、内容が偏っていたり間違ってる可能性があります。参考にする場合はご注意ください。 画面遷移図の役割 画面遷移図とは、画面とその移り変わりを図にしたものです。画面同士を矢印などでつなぎ、矢印の方向に画面が遷移することを表したりします。 最近はUI設計の成果物として、実際に画面遷移の操作をできるモックアップの開発も盛んになっています。しかし、それはそれで良いものですが、画面とその相互関係を一覧できる画面遷移図は、また別な価値のある資料です。画面遷移図を作ること、そして作り方を検討して改善していくことは、アプリケーションの設計において重要ではないかと思います。 画面遷移図の種類 画面遷

    画面遷移図の作成方法ついてのまとめ - Qiita
  • CSSレスポンシブデザインをSPAで使うと破滅する - 橋本商会

    レスポンシブデザインは あくまで見た目の調整、表示・非表示のコントロールなので 下手に使うと、デバイス毎にインタラクションが違うUIのstateが無茶苦茶複雑になっていく コンポーネントという概念が無かった時代の設計を、SPAに持ってくるのはおかしい 画面サイズ毎にCSSで手軽にを切り替える、というのなら良い しかし、画面サイズ毎にインタラクションが違う部品が出てくると設計が破綻する 画面サイズ毎のがごちゃ混ぜになる コードが追えなくなり、バグの温床になる では、どうするか? 素直に画面サイズ毎、デバイス毎、あるいはインタラクション毎のReactコンポーネントを書けばいい 使いまわせる部品は、コンポーネントとして切り出して再利用する 歴史を紐解く 2011年頃、レスポンシブデザインが生まれた 当時のwebにはコンポーネントが存在しなかった 単体で複雑な状態遷移をするインタラクティブなパーツ

    CSSレスポンシブデザインをSPAで使うと破滅する - 橋本商会
  • 「AndroidはiOSと同じデザインで!」と言われたときの対応案 - Qiita

    はじめに 「AndroidはiOSと同じデザインで!」と言われてどう実装しようか悩んでる方向けの記事です。 Androidアプリを作るなら当然マテリアルデザインガイドラインに合わせて1から画面設計するのが最高なんですが、そうはいかないことが経験上多いので対応案をざっくりまとめました。 諸注意 これは「iOSとAndroidUI対応一覧」ではありません。 iOSとAndroidで同じような見た目のUI部品でも作られた経緯や目的は違うので、比較して置き換えるようなことは基的にできないと思います。 とはいえなんの指標もないと辛いので、ここでは「iOSのこのUIAndroidで代用できるのはこれかもね」くらいのニュアンスで列挙しています。 必ずしもどのアプリにも言えるようなことではないので、あくまでたたき台と思ってください。 「なぜAndroidらしくする必要があるのか」についてはこ

    「AndroidはiOSと同じデザインで!」と言われたときの対応案 - Qiita
  • メールアドレスの確認フィールドをなくすべき理由

    UX Movementの著者、編集長。明快で効果的なデザインを愛し、ユーザのために日々奮闘しています。 メールアドレスは、もっとも間違いやすいフォームフィールドの1つです。 入力データにはさまざまな種類の文字による長い文字列が含まれているため、間違って入力してしまいがちです。これにより、ユーザーが間違ったメールアドレスを送信する可能性があるのです。 メールアドレス確認の問題 デザイナーは、メールアドレスの確認フィールドを追加することで、間違ったメールアドレスの送信を防ぐことができると考えています。メールアドレスの確認フィールドの追加で誤送信を何件か防ぐことはできるかもしれませんが、必ずしもすべてを防ぐことができるというわけではありません。 多くのユーザーは、メールアドレスの入力内容をコピーして、確認フィールドに貼り付ける傾向があります。これでは、ユーザーが間違ったメールアドレスを貼り付ける

    メールアドレスの確認フィールドをなくすべき理由
  • モードレスデザイン|ai

    はじめて iMacG3 を使った時、私はとても前向きな気持ちになった。説明書を読まなくても何をどうすればいいの分かったし、自分の思い描いた通りに動かすことができた。 道具は使う人の能力を拡張させると言うけれど、私はあの丸いマウスと一緒に、文章を書いたり、絵を描いたり、当に何でも出来る気がしたのだ。 それは Mac だけではなかった。iPhone も、iPadも、Apple 製品はいつも私を高揚させた。なぜ私はこんなにも惹かれるのか。不思議に思いながらも、私は Apple 製品を追いかけてきた。 どうして? ... 実はその秘密は既に明らかになっている。 それは、モードレスだからだ。 直感的だとか、シンプルだとか、一貫性があるとか、そういったものは表出された一部にすぎない。 この秘密は、 今から 9 年も前にインターネットに公開されたテキストにあっさり書かれている。ソシオメディアの上野学

    モードレスデザイン|ai
  • フォームをより使いやすくするためのJavaScript/CSSツール10選

    この記事はSpeckyboy Design Magazineからの翻訳転載です。配信元または著者の許可を得て配信しています。 10 JavaScript and CSS Tools to Enhance Your Forms フォームは多くのWebサイトにとって欠かせないものです。しかし私たちは、その細部にまでいつも気を配れるわけではありません。 フォームを改善する方法はたくさん存在します。バリデーションの追加や、マスクやその他のビジュアルガイドをインプットしたりすることが挙げられるでしょう。そしてこれは表面的な対処でしかありません。最終目標は、できる限り使いやすく魅力的なフォームにすることです。 この記事では、最適なフォームを作るための10の無料ツールを紹介します。 formbase formbaseは、CSS/SASSを使用してフォーム要素に改善されたデフォルト要素をもたらすパッケージ

    フォームをより使いやすくするためのJavaScript/CSSツール10選
  • viron_20180201

    CAMはエンタメコンテンツ、ビジネスバラエティメディア、ライフスタイルメディアを主軸に30以上のサービスを展開しています。エンタメコンテンツの分野では、国内外で圧倒的人気を誇るアーティストやアイドルグループとのパートナーシップを結び、オフィシャルファンサイトや動画関連サービスを運営しています。

    viron_20180201
  • 電子カルテのUI/UXを考える その1|Ken Miyoshi

    電子カルテが登場してから随分たつが、残念ながらいまだに素晴らしいものにお目にかかったことはない。特に、日のメーカーが開発したものは使いやすさまで考慮されているとは言いがたく、UIUXにも改善の余地がかなりあるように思う。 一般的にPC上でセキュリティのかかったものにログインするためには、利用者IDとパスワードを入力後にエンターすれば開く。電子カルテも同様で、多くのメーカーの場合、利用者IDとパスワードを入力してエンターすればログインできる。 これはF社の電子カルテであるが、利用者IDとパスワードを入力後にエンターするだけではカルテの画面にはならず、利用者氏名が表示されるのを待って、さらに「診療業務開始」をクリック(もしくは再度エンター)しなければならない。 診療業務(電子カルテ)以外の業務も選択できるようにするために、このようにしていると思われるが、多くのユーザーは1回のエンターでログ

    電子カルテのUI/UXを考える その1|Ken Miyoshi
  • CoreUI - Vue/Bootstrap製の管理画面UI MOONGIFT

    管理画面は主に運営元が使う画面になるので、デザインへのこだわりが殆ど感じられないことが多いです。しかし運営元が使いやすい画面でないと細かい制御がしづらかったり、サービスのステータス把握が遅れたりするのではないでしょうか。 そこで使ってみたいのがCoreUIです。VueBootstrapを使って作られた管理画面テンプレートです。 CoreUIの使い方 スクリーンショット多めで紹介します。まずはダッシュボード。このようなUIの管理画面が簡単に作れます。 ボタン。 ソーシャルボタン。 カード。 フォーム。 モーダル。 スイッチ。 テーブル。 タブ。 アイコン。Font AwesomeかSimple Line Iconsがサポートされています。 ウィジェット。 こんなウィジェットも。 チャート。 ログイン画面。 登録画面。 エラー画面。 CoreUIVueで作られていますので、表示する際にもW

    CoreUI - Vue/Bootstrap製の管理画面UI MOONGIFT
  • OSSを読んでAirbnbのホーム画面の実装を想像してみた

    OSSを読んで調査しながら、手を動かしているうちに出来上がったのがこちらです。 はじめに AirbnbのiOSアプリの実装に興味が沸いたのですが、Airbnbのソースを直接読むこともできません。そこで、似たような動作を実現しているOSSから内部実装を推測して自分でも書いてみることにしました。事前に調査したところ、既に似たようなことを考えている方がいて、大いに参考にさせて頂きました。感謝です。 今回の記事は、私が調査して気づいたことを再度整理した、という位置付けです。 これ以降の記述は下記のような読者を想定して書いていますので、ご承知おき下さい。 m(_ _)m iPhoneアプリ開発の経験は多少あるけれどもUIの実装は苦手 著名なアプリの実装に興味がある 画面の構成 TableViewが縦のスクロールを担い、各ジャンルのリストを横にスクロールしていく部分はTableViewの各rowの中に

    OSSを読んでAirbnbのホーム画面の実装を想像してみた
  • あたりまえインタフェース - 増井俊之

    簡潔で便利なインタフェースは業者が作るものだという意識が蔓延してないだろうか? たとえばAppleが便利なインタフェースを発表したら、「なるほどメーカが工夫したんだな、便利そう」とは思っても「これは論文になってるのかな」と気になる人は少ないと思う。 そういう例は昔からとても多いと思われる。Suicaや自動ドアは論文になってないだろうし、誰もが使うGUIや開発者が使うInterface Builderもそれ自体が論文にはなっていないだろう。自動ドアが無かった時代に自動ドアを発明しても論文にはなりにくいだろう。 すごく考えたり実験したりした結果としてシンプルで使いやすい洗練された新インタフェースができても業者がちょっと工夫したあたりまえなものだと思われる可能性が高いのではないだろうか。一旦あたりまえだと思われたら、それがいくら新しくて便利で画期的なものであっても、愚かな査読者は「あたりまえじゃ

    あたりまえインタフェース - 増井俊之
  • 行動を支えるデザイン 【ユーザー名編】|きよえ氏さん

    Connehito inc. ママリのデザイナー きよえ氏です。サービスデザイン全般を担っています。 先日、ママリの登録導線をリニューアルしました。その振り返りをしている際におもしろい改善を見つけたので、noteにまとめてみようと思います。 入力フォームのUI改善以下はママリの初回登録時に通る「ニックネーム登録画面」です。左がこれまでのUI、右がこれからのUIです。 ボタンや文言など全面的に改善を行ったのですが、その中で特に工夫したのは「入力フォームの表現」です。 入力フォームの右側に"さん"を配置することで、ママさん同士でコミュニケーションしやすいユーザー名を登録してもらえるように体験設計をしました。 ママリはママさん同士が会話をしながら課題解決を行う場所なので、コミュニケーションのしやすさは非常に重要です。現状のママリは、匿名でありながら、その先にいるママを感じられる、いわば"2.5次

    行動を支えるデザイン 【ユーザー名編】|きよえ氏さん
  • なぜ人は複雑なリモコンのようなWebサイトをつくってしまうのか - ビープラウド社長のブログ

    「複雑!すべての機能をとても使いこなせない」 数多くボタンが並んだAV機器のリモコンを見て、過去に思ったことがある人も多いでしょう。 しかし、いざ自分がWebサイトを企画する側になると、複雑なリモコンと同じものをつくってしまいがちです。 誰もが、シンプルで使いやすいWebサイトをつくりたいと思っているはずなのに、なぜ、そのようなことになってしまうのでしょうか。 順に考えていきます。 小さな労力で大きな価値を Webサイトを開発するリソース(お金、時間、人)は、どのような企業でも有限です。 そのため、なんでもかんでも思いついたものを、つくるわけにはいきません。 小さな労力でWebサイトをつくり、大きな価値を生み出す努力が必要です。 そのためには、当然ながらWebサイトの開発スコープを絞ります。 顧客の対象を絞る スコープを絞るには、顧客の対象を絞るのが1番手っ取り早い方法です。 たとえば、顧

    なぜ人は複雑なリモコンのようなWebサイトをつくってしまうのか - ビープラウド社長のブログ
  • つよいUI - transitkix design log

    …というものを最近考えていました。「画面デザインのOKももらったし、私の仕事は終わり!あとはエンジニアに指示書を渡すだけ」と一息ついた時にこそ、改めてデザインを見つめなおすべきです。 つよいUIであるための7つの視点 1.来、そこにあるはずの情報がない場合はどうなりますか? リストUIで載せる情報が0件、文章が空っぽ、画像がない時など 2.表示する要素が想定よりすごく多い/すごく少ない場合はどうなりますか? 数字の桁数、文章の行数、文章が入りきれない場合は文中・文末のどこを省略すべきか…など 3.ユーザーさんの立場によって、表示要素に変化はありませんか? ゲストとログインユーザー、無料会員と有料会員…など 4.ロード中、もしくはロードされるまで何が出ていますか? 通信中の表示、読み込み中の画像エリア…など 5.予期せぬエラーが起こった時、画面はどうなりますか? 通信エラー、リンク先のコン

    つよいUI - transitkix design log
  • キャンセルのキャンセル問題から考えるダイアログデザイン|Goodpatch Blog グッドパッチブログ

    この文脈では、「編集内容のキャンセル」という処理を続行しても良いかをユーザーに確認しています。続行に同意したい多くのユーザーは直感的に同じ表記の「キャンセル」を押したくなるでしょう。しかしそれでは編集のキャンセルが実行されません。 このキャンセルボタンが意味するのは、「『編集内容をキャンセルする』のキャンセル」なのです。つまり、ユーザーが望み通りに編集内容を破棄するためには、反対側のOKボタンを選ぶべきなのです。このような「キャンセルのキャンセル」は二重否定で意味がややこしくなるので避けなければなりません。 ここで「キャンセルのキャンセル」にならなければ良いということで、次のようにボタン名を変えてみました。 これでもう迷うことは無くなりましたか……? 私はこの修正は誤りだと判断します。「はい」「いいえ」は結果を予想しにくい表現なので、ダイアログのアクションボタンに用いることはあまり適切では

    キャンセルのキャンセル問題から考えるダイアログデザイン|Goodpatch Blog グッドパッチブログ