タグ付けされた質問 「user-interface」

人間のユーザーとのソフトウェアの相互作用に関する質問。

14
コードエディタは、インデントを使用せずに、コードのネストレベルを効果的に示唆できますか?[閉まっている]
同じXMLテキストに2つの表示オプションを提供するXMLテキストエディターを作成しました。1つはインデント(仮想)、もう1つは左揃えです。左寄せビューの動機は、XMLコンテキストの自動化された副作用であるインデントの干渉なしに、ユーザーがプレーンテキストまたはXPathコードのインデントに使用している空白文字を「見る」のを支援することです。 私は、ユーザーを支援する左寄せモードの視覚的な手がかりを(エディターの編集不可部分で)提供したいと思いますが、あまり複雑になりません。 接続線だけを使用してみましたが、それは忙しすぎるようでした。私がこれまでに思いついた最高のものは、下のエディターのモックアップされたスクリーンショットに示されていますが、私はより良い/より簡単な代替手段を探しています(コードをあまり必要としません)。 [編集] ヒートマップのアイデア(@jimpから)を取得すると、これと3つの選択肢が得られます-a、b、cというラベルが付けられています。 次のセクションでは、受け入れられた回答を提案として説明し、他の多くの回答やコメントからアイデアを集めます。この質問は現在コミュニティwikiであるため、お気軽に更新してください。 NestView インデントを使用せずにネストされたコードの可読性を向上させる視覚的な方法を提供するこのアイデアの名前。 等高線 NestView内の異なる影付きの線の名前 上の画像は、XMLスニペットを視覚化するために使用されるNestViewを示しています。この図ではXMLを使用していますが、この図ではネストを使用する他のコード構文も使用できます。 概要: 等高線は、ネストレベルを伝えるために(ヒートマップのように)シェーディングされています 等高線は、ネストレベルが開いているか閉じているかを示すために角度が付けられています。 等高線は、ネストレベルの開始点を対応する終了点にリンクします。 等高線の幅を組み合わせることで、ヒートマップに加えて、ネストレベルの視覚的な印象が得られます。 NestViewの幅は手動でサイズ変更できますが、コードが変更されても変更しないでください。これを維持するために、輪郭線を圧縮または切り捨てることができます。 空白行は、テキストをより消化しやすい塊に分割するためにコードを使用する場合があります。このような行は、NestViewで特別な動作をトリガーする可能性があります。たとえば、ヒートマップをリセットしたり、背景色の等高線を使用したり、あるいはその両方を行うことができます。 現在選択されているコードに関連付けられている1つ以上の等高線を強調表示できます。選択したコードレベルに関連付けられた等高線が最も強調されますが、ネストされたグループを強調表示するのに役立つ他の等高線も「点灯」できます。 さまざまな動作(コードの折り畳みやコードの選択など)を、等高線のクリック/ダブルクリックに関連付けることができます。 等高線の異なる部分(リーディングエッジ、ミドルエッジ、またはトレーリングエッジ)には、異なる動的な動作が関連付けられている場合があります。 等高線上のマウスホバーイベントでツールチップを表示できます。 NestViewは、コードが編集されると継続的に更新されます。ネスティングのバランスが取れていない場合、ネスティングレベルが終了する場所を想定できますが、関連する一時的な等高線は警告として何らかの方法で強調表示する必要があります。 等高線のドラッグアンドドロップ動作をサポートできます。動作は、ドラッグされる等高線の部分によって異なる場合があります。 エラーや状態の変更のための行番号付けや色の強調表示など、一般的に左マージンにある機能は、NestViewにオーバーレイする可能性があります。 追加機能 この提案はさまざまな追加の問題に対処します。多くは元の質問の範囲外ですが、有用な副作用です。 ネストされた領域の開始と終了を視覚的にリンクする 等高線は、ネストされた各レベルの開始点と終了点を接続します 現在選択されている行のコンテキストを強調表示する コードが選択されると、NestViewの関連するネストレベルを強調表示できます。 同じネストレベルでコード領域を区別する XMLの場合、異なる名前空間に異なる色相を使用できます。プログラミング言語(c#など)は、同様の方法で使用できる名前付き領域をサポートします。 ネスト領域内の領域を異なる視覚ブロックに分割する 読みやすくするために、コードに余分な行が挿入されることがよくあります。このような空のラインは、NestViewの等高線の彩度レベルをリセットするために使用できます。 複数列のコードビュー インデントなしのコードは、ワードラップまたは水平スクロールが必要になる可能性が低いため、複数列ビューの使用をより効果的にします。このビューでは、コードが1つの列の下部に到達すると、次の列に流れます。 視覚的な補助を提供するだけではありません 概要で提案されているように、NestView は、TreeViewコントロールに期待されるものとほぼ一致する幅広い編集および選択機能を提供できます。主な違いは、一般的なTreeViewノードには、エキスパンダーとノードアイコンの2つの部分があることです。NestViewの輪郭線には、オープナー(傾斜)、コネクタ(垂直)、およびクローズ(傾斜)の3つの部分があります。 インデントについて NestViewは、インデントされていないコードを補完しますが、従来のインデントされたコードビューを置き換えることはほとんどありません。 NestViewを採用するソリューションは、空白文字を含むコードテキスト自体に影響を与えることなく、インデントされたコードビューとインデントされていないコードビューをシームレスに切り替える方法を提供する可能性があります。インデントビューのテクニックの1つは「仮想フォーマット」です。タブまたはスペース文字の代わりに動的な左マージンが使用されます。NestViewを動的にレンダリングするために使用される同じネストレベルのデータは、より従来型のインデントビューにも使用できます。 印刷 インデントは、印刷されたコードを読みやすくするために重要です。ここでは、タブ/スペース文字と動的な左マージンがないため、テキストは右マージンで折り返されても、インデントされたビューの整合性が維持されます。行番号は、コードがワードラップされる場所とインデントの正確な位置を示す視覚的なマーカーとして使用できます。 画面の不動産:フラット対インデント NestViewが貴重な画面の不動産を使用するかどうかの質問に対処します。 等高線は、コードエディターの文字幅と同じ幅でうまく機能します。したがって、12文字幅のNestView幅は、等高線が切り捨て/圧縮される前に12レベルのネストに対応できます。 インデントビューが各ネストレベルに3文字幅を使用する場合、ネストが4レベルのネストに達するまでスペースが節約されます。このネストレベルの後、フラットビューには、各ネストレベルで増加するスペース節約の利点があります。 注:コードには4文字幅以上のインデントが推奨されることがよくありますが、XMLは多くの場合それよりも少なく管理されます。また、仮想フォーマットでは、配置の問題のリスクがないため、使用するインデントを少なくすることができます …

25
電子メールアドレスの検証はどこまで行う必要がありますか?
電子メールアドレスの検証はどこまで行われるべきかと思います。私の分野は主にWeb開発ですが、これはどこでも当てはまります。 私はいくつかのアプローチを見てきました: 「@」が存在するかどうかを単純に確認します。これは非常に単純ですが、もちろんそれほど信頼できません。 標準の電子メール形式のより複雑な正規表現テスト 完全な正規表現に対するRFC 2822 -これに伴う問題は、多くの場合、電子メールアドレスが有効であるかもしれないということですが、それはおそらく、ユーザーがどのような意味ではありません DNS検証 SMTP検証 多くの人が知っているかもしれませんが(多くの人は知らない)、電子メールアドレスには、ほとんどの人が通常考慮しない多くの奇妙なバリエーションがあります(RFC 2822 3.4.1を参照)が、あなたの検証:電子メールメッセージをアドレスに送信できるようにするか、それともユーザーが入力することを意図したものであるかを確認しようとしていますか(それ以外の場合は、「有効」 'アドレス)。 私が検討したオプションは、より難解なアドレスで警告を出すだけですが、リクエストは通過できますが、これによりフォームがより複雑になり、ほとんどのユーザーが混乱する可能性があります。 DNS検証/ SMTP検証は非常に簡単に思えますが、DNSサーバー/ SMTPサーバーが一時的にダウンし、ユーザーがどこかに登録できない、またはユーザーのSMTPサーバーが必要な機能をサポートしていないという問題が発生することを予測しています。 ここにいる経験豊富な開発者の中には、これをどのように扱うのでしょうか?私がリストしたもの以外のアプローチはありますか? 編集:私はすべての中で最も明白なことを完全に忘れて、確認メールを送信しました!それを指摘してくれた回答者に感謝します。はい、これは非常に簡単ですが、関係者全員の面倒な作業が必要です。ユーザーは電子メールを取得する必要があり、開発者はユーザーデータが有効であると確認される前にユーザーデータを記憶する必要があります。

17
ユーザーインターフェイスクラスをコマンドラインインターフェイスに置き換えることができると考えるアーキテクチャを設計することは良い考えですか?
コード完了ページ25では、通常のユーザーインターフェイスクラスをコマンドラインクラスで簡単に置き換えることができるとよいと言われています。 テストの利点を知っていて、それがもたらす問題についてはどうでしょうか? この余分な作業は、Webプロジェクトとモバイルプロジェクトにとって本当に成果がありますか?中小規模のプロジェクトはどうですか。同じルールが適用されますか?設計がより複雑になる場合はどうしますか?

24
一部のプログラマーが開発のUI部分を嫌うのはなぜですか?[閉まっている]
私が会った多くのプログラマーは常に「彼はUIの人ではない」と言っています。実際、最近の開発は、Web、Windows、Linux、OSX、またはその他の種類の開発に関係なく、見栄えの良いUIを備えたソフトウェアで構成されています。なぜこれほど多くの開発者がUIの動作を好まないように見えるのでしょうか?

9
一般的に言って、すべての機能部分を作成するか、UIを最初に動作させるのが良いのでしょうか?
一般的に言って、すべての機能部分を作成するか、UIを最初に動作させるのが良いのでしょうか? あなたが大きな何かに取り組んでいると仮定すると、UIの前にすべての機能データ収集ブロブを動作させる、一般的に受け入れられているプラ​​クティス、すべてのUIを一度に1つずつ動作させる、または途中で何かを行うのは一般的ですか? 管理しやすい部分に細分化することは誰もが知っていますが、問題は最終的にはUIが管理可能な部分に含まれるかどうかです。 この例の場合、1つのルートウィンドウを備えたGUIアプリケーションを考えてみましょう。ただし、さまざまなデータコンポーネントを分離するためにさまざまなドックに12個以上のタブがあります。個々のタブには、機能ユニットの観点から、その背後にある比較的複雑な可動部品のセットがあります。 この特定の問題の応用例はあるここに付随ブログやオリジナル商品。

6
エラーについてどのくらいの情報をユーザーに表示する必要がありますか?
アプリケーションは常にエラーをスローできます。このようなエラーが発生した場合、ユーザーにアプリケーションに要求したことが成功しなかったため、ユーザーに通知する必要があります。 ただし、ユーザーにはどの程度の情報を提供する必要がありますか?私たちのほとんどは、スタックトレースを表示しないことに同意すると思います(スタックトレースは、ユーザーに表示されるエラーメッセージに含まれるべきですか?)ユーザー。 たとえば、例外をサポートする言語(.net、java)には、共有する例外の種類、例外が発生した場所、および例外に沿った明確なメッセージがあります。これもユーザーに非表示にする必要がありますか?または、とにかくこれを表示する必要がありますか?または、一般的なメッセージを表示する必要がありますか?または、基になる例外が何であるかに基づいて、いくつかのメッセージの1つを表示する必要がありますか?

4
GUIプログラミングでスレッドの安全性を確保するのはなぜ呼び出し側の責任ですか?
多くの場所で、UIコンポーネントを更新するときにUIスレッド上にいること(具体的には、Javaスイングでは、イベントディスパッチスレッド上にいることを確認することは呼び出し側の責任であることは、標準的な知恵1です) 。 これはなぜですか?イベントディスパッチスレッドは、MVC / MVP / MVVMのビューの問題です。ビュー以外の場所で処理するには、ビューの実装と、そのビューの実装のスレッドモデルとの間に密結合を作成します。 具体的には、Swingを使用するMVC設計のアプリケーションがあるとします。呼び出し元がイベントディスパッチスレッドのコンポーネントの更新を担当している場合、JavaFX実装のSwing View実装を交換しようとすると、代わりにJavaFXアプリケーションスレッドを使用するようにすべてのプレゼンター/コントローラーコードを変更する必要があります。 だから、私は2つの質問があると思う: UIコンポーネントのスレッドの安全性を確保するのは、呼び出し側の責任なのはなぜですか?上記の推論の欠陥はどこにありますか? これらのスレッド安全性の懸念を疎結合しながら、適切にスレッドセーフであるようにアプリケーションを設計するにはどうすればよいですか? MCVE Javaコードを追加して、「呼び出し側の責任」が意味することを説明します(ここには、私がやっていませんが、できる限り最小限にするために他の良い習慣があります)。 責任者である発信者: public class Presenter { private final View; void updateViewWithNewData(final Data data) { EventQueue.invokeLater(new Runnable() { public void run() { view.setData(data); } }); } } public class View { void setData(Data data) { component.setText(data.getMessage()); } } …

14
自動化されたユーザーインターフェイステストはどのような問題を解決しますか?
現在、自動化されたユーザーインターフェイステストを調査中です(現在、自動化された単体テストと統合テストを行っています)。 SeleniumとTelerikを見てきましたが、後者の方がはるかに柔軟なレコーダであるため、後者を選択のツールとして採用しました。テスターがあまり多くのコードを書くことは望ましくありません。 ただし、全体的なメリットを理解しようとしています。人々の意見はどのようなもので、どのようなものがうまく機能し、何がうまくいかないのでしょうか? 私たちのシステムは絶えず開発されており、(ウェブベースの)プラットフォームの新しいバージョンを定期的にリリースしています。 これまでのところ、主な利点は、特にプラットフォームの複数のクライアント展開での回帰テストにあります。 他の人の意見を本当に探しています。私たちはそれが正しいことだと「考える」が、すでに忙しいスケジュールの中で、さらなる洞察を探している。

4
JavaScriptのプロンプト、確認、およびアラートは「旧式」と見なされる[終了]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 最近、私はジム用のウェブベースの管理システムを開発しています。以前のアプリはVisual Basicで開発されました。新しいアプリの場合、すべてのフロントエンドスクリプトはjQueryを使用し、サーバーはPHPとMySQLを実行しています...ご存じのとおり、典型的なel-cheapo linuxベースのスタックです。 とにかく、最近JavaScriptのプロンプト、確認、警告メッセージダイアログがあまり使用されていないのはなぜかと思っていました。モーダルウィンドウ用のjQueryプラグインと、言語が既に提供しているものを模倣しようとするアラートメッセージが多数あり、すべてのブラウザーは適切にサポートする必要があります。 複雑なフォームや特別なニーズには、ハンドメイドまたはプラグインベースのソリューションを使用しても問題ありませんが、単一の値を要求するか、レコードの削除を確認するだけの場合、Webアプリケーションにこのようなオーバーヘッドを追加するのはなぜですか?さらに、プロンプト、確認、警告を使用すると、iOSとAndroidでメッセージダイアログがうまく調整されます。

2
効率を維持しながら、ビジネスロジックからユーザーインターフェイスを分離するにはどうすればよいですか?
コンボボックスで10個の異なるオブジェクトを表すフォームを表示したいとします。たとえば、トマトを含む10種類のハンバーガーのうち1つをユーザーに選択してもらいます。 UIとロジックを分離したいので、コンボボックスに表示するためにフォームにハンバーガーの文字列表現を渡す必要があります。そうでない場合、UIはオブジェクトフィールドを掘り下げる必要があります。次に、ユーザーはコンボボックスからハンバーガーを選択し、コントローラーに送信します。ここで、コントローラーは、フォームで使用される文字列表現(おそらくID?)に基づいて、ハンバーガーを再度検索する必要があります。 それは信じられないほど非効率ではありませんか?既に選択したいオブジェクトがありました。オブジェクト全体をフォームに送信してから特定のオブジェクトを返した場合、フォームがそのオブジェクトへの参照をすでに返しているため、後でそれを見つける必要はありません。 さらに、私が間違っていて、実際にオブジェクト全体をフォームに送信する必要がある場合、UIをロジックから分離するにはどうすればよいですか?

6
優れたユーザーインターフェイスのインスピレーションはどこで得られますか?[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 私が現在アップグレードしているデスクトップアプリケーションのメイン画面インターフェースを設計する限り、私は精神的なブロックを持っています。このプログラムを最初に開発したとき、画面解像度は640 X 480でした。今日では、複数の画面解像度があります。 デスクトップアプリケーションの優れたメイン画面レイアウトのアイデアはどこにありますか?

3
職場のソフトウェアにアワードポイントやゲーム機能を追加することは、プログラミングコミュニティの間ではあまり見られないでしょうか?
仕事での私の責任の1つは、労働者がすべての情報を入力するのに役立つ内部ツールを構築することです。Windowsフォームデータベースツールに似たエンタープライズアプリケーションです。 したがって、Word + Excelのコンボアプリケーションを開発するのとそれほど違いはありませんが、このワークグループの平均的な人は20〜40歳の女性またはおしゃべりな男性タイプです。加えて、私はこれらの人々全員が日常的にFacebookに深く関わっていることを知っています。 新しいインターフェイスをFacebookの機能に似せてスタイル設定すると、どれほど悪いことでしょう。人々は、さまざまな種類のフォームに記入し、基本的にゲームのように互いに競い合うと、アワードポイントやスタッフを獲得できます。人々がそれを完成したとき、それは彼らの壁に投稿され、誰もがFacebookのようにコメント/いいねをすることができます。そして、彼らは楽しみのためにピアレビューをしているようです。 報酬は、私が想像するほど素晴らしいでしょう。これらの人々はFacebookやFacebookゲームに夢中なので、ポイントや実績を競い合って獲得しようとするため、生産性が向上します。 これは、人々に「ゲームを提供することにより、彼らをより熱心に働かせること」を利用しているのでしょうか、それとも職場での幸福を改善する何かと見なされますか?

12
新しいWebサイトに「Twitter / Facebookでサインイン」を使用することの長所と短所は何ですか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私と友人は小さなフォーラムサイトを立ち上げようとしています。ユーザーのログインに「Facebook / Twitterでサインイン」APIを使用することを検討しています(おそらく、たとえばLanyrdなど)。私はこれらのいずれも以前に使用したことも、ユーザーログインを使用してサイトを実行したこともありません。 これらのAPIの長所と短所は何ですか?具体的には: 開発者としてそれらを使用することでどのような利点が得られますか?どんな欠点がありますか? エンドユーザーは実際にそれらを好き/嫌いですか? これらのAPIで技術的/物流上の問題を特に経験しましたか? ここに私がこれまでに得た長所と短所を示します。 長所 ユーザーにとってより便利です(2回のクリックで「登録」、1回でサインイン) おそらく独自のログインシステムを維持する必要はありません 短所 ログインプロセスを制御できない アカウントへの何らかのアクセスがあることを心配しているFacebook / Twitterユーザーを除外する Facebook / Twitterアカウントが侵害されると、サイトのユーザーアカウントが侵害されます。 独自の代替ログインシステムを維持しない場合: ログインシステムのFacebook / Twitterへの依存 Facebook / Twitter以外のユーザーをサイトから除外する

4
GUIの壊れやすいではなく、保守可能なユニットテストを記述する方法
GUIアプリのUIユニットテストを作成してみましたが、最初に作成したときにはうまく機能しますが、設計が変更されるたびに(つまり、非常に頻繁に)壊れるという問題に直面しています。GUIの保守可能な単体テストを作成するためのガイドラインを見つけるのに苦労しています。 今のところ、私が発見したことの1つは、「このコンポーネントは入力データをどこかに表示する必要がある」というテストが適切であることです(HTMLでは非常に簡単です)。通常、コンポーネントの特定の部分の特定の状態を確認するテストは脆弱です。クリック-クリック-クリック-期待のようなテストは、ユーザーの行動と基礎となるビジネスロジック(最も重要な部分)を追跡しようとするため、通常は脆弱です。良いテストを書くにはどうすればいいですか? もっと正確に言うと、UIで何をテストできるかについて、正確なテスト方法ではなく、いくつかのパターンを知りたいです。命名規則と固定識別子は優れていますが、コアの問題、つまりGUIが大きく変わるという問題は解決しません。変化する可能性が最も低い動作をテストしたいと思います。テストする正しいものを見つける方法は?

2
「入力の取り消し」はどのように動作する必要がありますか?
Undo / Redoスタックを含むJavaアプリを実装しています。一部のアプリ(Mac OS XのTextEditなど)では、テキストを入力した後、[編集]メニューから[入力を元に戻す]を選択できます。私も自分のアプリにそのようなことを実装したいと思いますが、それがどのように振る舞うべきかについてのガイドラインを見つけるのに本当に苦労しています。 試行錯誤を繰り返して、TextEditのUndo Typingの動作についての私の推測は次のとおりです。 ユーザーが新しい文字を入力する(または削除キーを入力する)ときに、次のいずれかの状況が発生しない限り、元の[元に戻す]項目が元に戻すスタックの最上位にある場合、それをマージします 少なくとも15秒間非アクティブな状態が続いた後にユーザーが入力を続けた後は、常に新しい[元に戻す]項目を作成します。 ユーザーが長時間入力し、何らかの条件が満たされた後は、常に新しい[元に戻す]項目を作成します(これが時間ベースであるか文字数ベースであるかはわかりません)。 テキストを選択してから削除または上書きする場合は、常に新しい[元に戻す]項目を作成します(テキストを選択し、変更を加えずに元の挿入ポイントに戻って入力し続けても、トリガーされません) 実際には、Appleの戦略は機能しているように見えます(少なくとも私がタイプするときは機能します)が、最後のポイントで述べたように、私は実際にルールを理解することができませんでした。また、他のプログラムはMicrosoft Wordなどの異なる規則に従っているようです。Googleは、Undo Typingの実装に関するルールの定義済みリストを公開しておらず、その動作方法に関するベストプラクティスに遭遇していません。それで、それはどのように振る舞うべきですか?それとも、プログラマーの気まぐれ次第ですか? 編集:明確にするために、今は実装の詳細には興味がありません。特に、これを説明する信頼できる参照(ベストプラクティスやユーザーインターフェイスドキュメントなど)が存在するかどうか、または複数の製品にまたがってどのように実装されているかの説明について興味があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.