「user-select：none」は悪いUXですか？
今日は同僚と話し合っていました。私は彼女に "user-select：none"-ユーザーがテキストを選択できないようにするCSSプロパティを示しました。
私にとって、このプロパティにより、ページ上でよりアプリのようなエクスペリエンスを作成できるようになりました-ダブルクリックなどのイベントによって、アプリで選択できない領域（ナビゲーションバーのオプションなど）でテキストが選択されないようにしました、カスタム選択要素、ラベルなど）。
私の同僚は、それが磨きを加えることに反対し、ユーザーがウェブアプリのテキストを選択してコピーできるようにするべきだと提案しました。
UXの観点から、これに関するコンセンサスは何ですか。サイトをアプリのように感じさせようとすべきでしょうか？または、WebはWebのように感じるべきですか？このようにデフォルトの動作を変更しないことを意味しますか？
user-select: noneにアプローチする簡単な方法があり、それは単一の質問をすることです：
テキストを選択することは、そこで画面をタッチした場合にユーザーが意図する1次/ 2次の相互作用になるのでしょうか、それとも、ユーザーが実行しようとしていたタスクの妨げになるのでしょうか。
画像カルーセル（それらを愛するか、それらを憎む）は、この素晴らしい例です。タッチインターフェイスで、カルーセルを操作しようとしているときに、指を押し下げてから右または左にスライドすると、何が起こりますか？カルーセルを回転させますか、それとも指で画像を選択しますか？
スクロール中に個々のカルーセル画像要素が誤って選択された場合、それを選択解除することもできますか、それをタップして選択を解除しようとすると他のことを実行する可能性のある選択された要素が表示されます（ページナビゲーション、img要素はa要素で囲まれています）？または、カルーセルの構造を構成するdivの配置に応じて、各画像にわたって選択ハイライトを残している上位レイヤーをどうにかして選択しましたか？ （私はこれらすべてが不十分にコーディングされたカルーセル実装で発生するのを見てきました）
一般的に言えば、これは、提示されたオブジェクトのセットをナビゲーションコントロール（画像のスライドリスト）として機能させたい場合であり、ブラウザがタッチを選択コマンドとして解釈した場合、その役割に干渉し、コントロールと対話するようになります。イライラする。
user-select: noneを使用する際の目標は、常にユーザーのフラストレーションを減らすことに限定する必要があります意図しない使用するコントロールの主要なタスクの目的を実行しようとすると簡単に発生する可能性がある対話から生じる選択オン。
「コンテンツを選択してコピーする人からコンテンツを保護するのはどうですか？」あなたが尋ねる傾向があるかもしれません。その答えは常に：いいえ。貧弱なUXであるだけでなく、不合理にも無意味です。あなたのコンテンツを真にコピーしたいと思っている人は誰でもそのコンテンツにアクセスできます。あなたがたどり着くのがいらいらしただけで、彼らがしていることが倫理的であるかどうかを気にする傾向が少なくなります：本質的に道徳的離脱を促進し、彼らの評価スキーマが彼らの通常の倫理スキーマと欲求不満のバランスをとれるようにしますあなたと一緒に、あなたのコンテンツをコピーするような行為を自己正当化する際の認知的不協和音のしきい値を減らします。
user:select noneがセキュリティ要素になることは決してありません。著作権侵害などからのより高いレベルのセキュリティを達成することを期待してそれを使用しないでください。あなたのコンテンツはまだソース内にあります（そして、スクリーンショットを撮るのに十分簡単です。侵害を追跡しようとしているかどうかを見つけるのはさらに困難です）。
コンテンツテキストの選択を防ぐためにuser-select: noneを使用しないでください。この場合、ブラウザ自体がスクロールと選択のどちらを行うかを決定する責任があり、2つの潜在的なアクション（選択またはスクロール）の間でユーザーの意図を識別する際に適切にそのジョブを実行するために信頼する必要があります。常に例外はありますが、これらの2つのアクションは、グローバルに一貫した予期される相互作用であることを覚えておいてください。それらに干渉すると、アプリケーションが予期したとおりに動作しなくなる可能性が高く、これがフラストレーションの主な原因になります。
個人的には、あなたはあなたの例の使用で正しい方向に進んでいると思います。
user-select: noneは、明確な必要性に基づいてのみ使用される非常に鈍い刃物であることに注意してください。磨きをかけることはできますが、コンテキストから選択しても意味がないと思われる場所では使用しないように注意してください。ただし、実際には、アプリケーションを使用している人が特定の理由で選択できるようにしたい場合があります。それを選択できれば、コントロールが公開する主要なタスクを実行しようとするときに、意図された相互作用に深刻な干渉を与えません。
この良い例は、モーダルエラーダイアログです。それらを選択不可にして、何らかのやり取りでそれらが削除されるようにしたり、何らかの合理化されたエクスペリエンスを意図したものに対するいくつかの同様の理論的根拠を使用したりするのは魅力的かもしれませんが、誰かがエラーに直面して見たい場合、これは非常に苛立たしいかもしれませんそれをサポートするために報告することはできますが、そうするために簡単にコピーすることはできません。影響を与える場合、特に特定の環境内で提供されている標準の対話モードを削除する場合は、常に注意と軽いタッチを無視してください。
一般的に、エラーメッセージの例のように、情報が含まれている（または含まれている）ときはいつでも、新しい情報を含まない制御アクションではなく、ほとんどすべての場合にuser-select: noneを適用すべきではありませんそれ。これは、コンテンツが同じ画面または密接に関連する画面の他の場所で選択可能な形式で表示されない場合に特に当てはまります。例外は常にありますが、単にアクションワードの代わりにコンテンツが表示されるuser-select: noneを適用するよりも、何かを実装して別の制御方法を見つける方法を再評価する方が一般に良いと警告します/一般的な用語/ etc。
一部の人々は、（一部の）モバイルアプリケーションによって、これが標準の対話の程度を取り除いたと主張するでしょう。より広い、最もグローバルなコンテキスト内では、それはまだ標準の相互作用であり、それらのアプリケーションの多くはそうすることによってユーザーエクスペリエンスを低下させるか、選択を行う機能を提供しないことによって単にプログラミングでずさんになっていると思います特に無効にするのではなく、場合によってはそうなります）。
特に、別のエージェント（Webブラウザーなど）を介してアプリケーションを表示する場合、ユーザーエージェントがコンテンツの相互作用に関する独自のメソッドをできる限り保持できるようにすることが重要です。これにより、ユーザーエクスペリエンスの適合性と一貫性が向上するだけでなく、プラットフォーム/エージェント間の互換性が高まり、個人的に予測できないユースケースや環境全体で将来の証明と機能を保証することもできます。
一般に、グローバルに使用しないでください。
多くの場合、ユーザーはいくつかのテキストを選択します。おそらく、何かをハイライトしてテキストの一部を友達に見せたり、テキストをコピーしたり、テキストをマークして読み取りやすくしたりします（テキストがかなり幅広で、文中のテキストの折り返しを追跡するのは難しい）。
しかし、それが良いオプションである本当に良い例があります。
ボタン
ユーザーがボタンのテキストを選択できるようにすると、ユーザーはボタンをクリックしたと思う可能性があるため、ボタンの選択ハイライト効果を無効にします。
Xを改善するためにテキスト選択の強調表示を無効にするCSSルールコードが書かれたページ
行番号ではなくコードをコピーしたいので、行番号のみの強調表示を無効にします。
ページを水平方向にドラッグしてナビゲートできるサイト。
ユーザーがテキストを選択できるようにすると、ナビゲーションが非常に難しくなります。
ただし、そのようなサイトがある場合は、コンテンツを掲載しないでください。リッチテキストコンテンツを選択可能にする必要があるためです。
ここでの良い解決策は、次のタイトルページに水平方向にドラッグできるタイトルサイトを作成することです。コンテンツを表示するには、ボタンを押してコンテンツページに進む必要があります。
「アプリエクスペリエンス」についても説明しましたが、そうです、テキストをコピーすることはほとんどできません。私が個人的に本当にいらいらするのは、アプリでコンテンツをまったくコピーまたはハイライト表示できない場合です。たとえば、Facebookアプリの投稿—投稿に応答するコメント全体をコピーできますが、個々の単語を強調表示することはできません。
ハイライトを無効にするかどうかを決定する必要があります。テキストの強調表示が使いやすさに悪影響を及ぼさない場合（水平方向のドラッグなど）、特にデスクトップユーザーがテキストをコピーできるようになっているため、無効にすることはありません。
より良い：テキストの強調表示のエクスペリエンスを強化します。
Medium.com 複数のオプションを提供します。強調表示されたテキストでできること：
ユーザーがあなたのテキストをどうするかを考えてください。ユーザーのニーズをサポートします。
ただし、Google Fontsのように、さらに悪化させることもできます。
「セレクションリーダー」という人もいます。私もその一人です。私は（何らかの理由で意識的に知られていない）、テキストを読んでいるときにテキストを選択する傾向があります。私がそうすることを止めるサイトは私を非常に悲しくさせ、私のユーザー体験を台無しにします。
私はまた、現在のトップの回答が何であるかという点に完全に同意しません。何かを選択するたびにポップアップ表示されるものは、選択リーダーを非常に困らせます。
アプリのようにしようとするのはやめてください！私のコンピュータは電話ではありません！あなたのサイトを使用するときに、電話で実行できる操作だけに制限されたくありません！
さらに読む： http://blogs.msdn.com/b/oldnewthing/archive/2015/05/28/10617693.aspx
テキストを選択できないことは、最新のWebサイトに現在存在する最も煩わしいユーザーフレンドリーなCSSプロパティです。
理由：
- 私たちのウェブサイトがそうでないものであるかのように振る舞おうとしないでください。これはモバイルアプリではありません。アプリケーションでテキストを選択できないのは、テキストボックス内にないため、理由により選択することが想定されていないためです。
- モバイルエコシステムは、「パワーユーザー」PCシステムとはまったく異なります。コンピューターでWebサイトを使用するほとんどの人は、仕事をやりたいと思っています。あるいは、[〜＃〜]自由[〜＃〜]マウスのために、モバイルデバイスで実行できなかったほとんどすべてのことを行いますそしてキーボードはそれらを与えます。
- 誰かがテキストのコピーを制限する理由はわかりません。面倒で、ユーザーレベルでの操作を制限する場合は、HTMLコードに少し触れて、必要なものをコピーし、絶対にあなたのウェブサイトを使用しないでくださいにします。
私はこれが少し過度に劇化された-であることを知っていますが、それをしないでください。
編集：これは、そのプロパティでコピーされる実際の理由がないテキストを含むボタンまたはラベルがfalseであることを意味するのではなく、実際にはdesirableです。
それが良いUXである多くのコンテキストがあり、それが悪いUXである多くのコンテキストがあります-ワンサイズフィットはありませんすべての答え。
質問にフラグを立てるときに、クリックされたときにテキストを強調表示するボタンまたはアクションは、UXとしては良くなく、ユーザーがそのテキストを強調表示する必要がある状況はほとんどありません。
ただし、テキストの本文は無効にしないでください。そのテキストが強調表示される原因となる操作がある場合は、メディアに明らかに不適切であるため、再検討する必要がある場合があります。
そして、他の場所で述べたように、テキストのallの強調表示を無効にしないでください。あなたがそれをするつもりなら、それは非常に選択的でなければなりません（ボタン、基本的に）。
標準のアプリケーション機能（ブラウザでテキストを選択するなど）をいじることは、ほとんどすべての場合に悪い考えです...ユーザーは自分が行ったアクションを実行することを期待しています。あなたがそれを壊したので、彼らはそれができません。そのような単純な。
経験則：
- すべての場合において、テキストの強調表示を無効にすることは信じられないほどばかげています。誰もそれを強調したくないと思っていても、あなたは決して知りません。あなたは人々が近づいていることに驚かれることでしょう。
- 何らかの方法でハイライト表示するときにUIが壊れている場合は、ハイライト表示を無効にするとよいでしょう。まれですが、発生する可能性があります。 「UIを壊す」は、のようなものです。
- あなたがすることができないはずのときにスクロールすることができます
- ユーザーに誤った印象を与える（たとえば、不可能なことをできる）
これが便利な機能だと思ったコンテキストは1つだけあり、それはa gameのコンテキストでした。
プレイヤーがマウスを使って操作しているプレイエリアがありました。そのプレイエリアには、テキストラベルの付いたオブジェクトがありました。時々、プレーヤーはオブジェクトをクリックするつもりでしたが、代わりにラベルにテキストをマークしました。これはユーザーがやりたいことではなかったので悪いことでした。設定user-select: noneテキストラベルで問題を修正しました。これは良い考えでした。
一人で作業している場合は、デフォルトで無効にして選択的に有効にするのが好きです。
メニュー項目のテキストまたはボタンのタイトルを選択しても、最終的な製品に多くの価値はありません。ユーザーの操作によって、テキストノードに奇妙な背景が追加され、デザインが破損する場合があります。 （多分私が知らないユーザビリティの側面があるのでしょうか？）
テキストの選択が役立つと思う唯一のケースは、ドキュメントや雑誌などの有益なテキストがある場合、またはページの目的がテキストを提示することである場合です。
ただし、チームで作業している場合、ブラウザーがページを配信するデフォルトの方法をオーバーライドし、新しいチームメンバーがバグを引き起こす可能性のある不要な情報を事前に知る必要があるため、これは問題ないと思いますか？ （現時点では、このプロパティによって引き起こされる可能性のあるバグについて考えることはできません）。
すべての機能と同様に、あなたがそれに気を配り、あなたが何をしているかを知っているなら、解決できない重大な問題があってはなりません。