ユーザー名にスペースを許可しない理由は何ですか？
私は開発者です。 UX担当者から、ユーザー名にスペースを含めるように依頼されています。注意点は、それらはどこでも許可される必要があるということです。
したがって、ユーザー名「JohnDoe」を入力すると「John Doe」は「J ohn D o e」と同じになります。
ユーザー名は「JohnDoe」として保存され、ログイン送信時にスペースを削除して、保存されているユーザーと照合できるようにします。
開発チームは、それについて私たちが嫌いなものがあることに同意しますが、「標準的な慣習ではない」以外に、それに対する説得力のある議論を実際に考えることはできません。
これを行う際に、私たちが考えていないことに注意する必要があることはありますか？
ユーザー名にスペースを入れない理由はいくつかあります...
...そのほとんどは適切な実装で解決できます：
サードパーティのソフトウェアでテストする必要があります。ソフトウェアがユーザー名にスペースを許可している場合でも、サードパーティのソフトウェアライブラリを使用してユーザー名を処理している場合は、スペースを許可しない可能性があるため、最低限のテストコンプライアンスが必要であり、最悪の場合、非準拠ライブラリのユーザー名のスペースを処理するアダプターを作成します。 。
ブラウザは空白を折り返します。したがって、ユーザー名が
J a s o nの場合、ブラウザで行の最後に表示されるときに、ユーザー名がぎこちなく折り返されることがあります。これは、HTMLでスペースを改行なしとしてレンダリングすることで回避できます。- ユーザー名の解析が困難になります。最も注目すべきは、ユーザーに言及することを許可するアプリケーション（例：
that reply from @tohster really sucked）の場合、スペースが関係していると、言及の解析が困難になる可能性があります。これは、注意深い実装で回避することもできます（たとえば、Facebookでは、スペースを含む名前でユーザーを言及できます）。 - 先頭と末尾の空白は慎重に管理する必要があります。ブラウザでユーザー名がレンダリングされるとき、
_Jason、Jason_、Jason（下線をスペースに置き換える）を区別するのが難しい場合があります。そのため、ユーザーのなりすましまたは混乱。これも、先頭/末尾の空白を禁止するか、改行しないスペースを使用してユーザー名が折りたたまれないようにすることで回避できます。 - 連続する空白は識別が難しい場合があります。たとえば、
Jason Bourne、Jason Bourne、Jason Bourneを区別するのは難しい場合があります。特に、他のユーザーがユーザー名を入力している場合（たとえば、メッセージを送信したり、ユーザーに言及したりする場合）。これは、連続する空白を禁止するか、またはそれを使用することで回避できます。
これらはどれもショーを停止する特定の問題ではないので、空白を適切に処理するために必要な労力/コストを喜んで受け入れるかどうか、および同様の空白のユーザー名で視覚的な差別化の問題に対処できるかどうかの問題です。
- これは説得力があるように聞こえませんが、実際には、この一連の複雑さは通常、大多数の企業がスペースを含むユーザー名を許可しないのに十分です。
Microsoft Windowsは、何年もの間ユーザー名にスペースを許可してきた大規模なソフトウェアの注目すべき例です。とはいえ、上記の問題のいくつかのため、MicrosoftでもWindowsユーザー名にスペースを使用しないことを推奨しています。から このMSDNドキュメント ：
ログオン名には、スペース、ピリオド、ダッシュ、アンダースコアなど、他のすべての特殊文字を含めることができます。ただし、アカウント名にスペースを使用することは、通常はお勧めできません。
しかし、あなたの場合...
..あなたのUX担当者は、スペースを許可するように求めています入力中ですが、他のすべてのものについてはそれらを取り除きます。したがって、ユーザーはJ ason Bourneを入力できますが、サーバーによって解決されると、JasonBourneが応答として表示されます。
ユーザー名入力では、先頭と末尾のスペースのトリミングがやや一般的ですが（カットアンドペースト操作で不要な先頭または末尾の空白が挿入されることがあるため）、スペースの内側に名前を付けることはできませんあなたがそれらを取り除くだけなら、アイデア。
あなたのUXデザイナーは、これがUXの摩擦を減らすと信じているかもしれませんが、実際にはそうではありません。通常、ユーザー名にはスペースが含まれていないため、ユーザーが無効な入力を入力したり、暗黙的にスペースを削除したりすることは、UXにとって非常に煩雑です。ユーザーが再度ユーザー名を確認できるように、インタースティシャルスペースを検出してユーザー（Usernames can't contain spacesなど）に通知することをお勧めします。
- たとえば、ログイン入力が
Jason [email protected]を黙って受け入れる場合、ブラウザのオートコンプリートはそのユーザー名を記憶し、将来誤って自動入力する可能性があります。無効な名前を拒否してユーザーに通知することをお勧めします。 - たとえば、新しいユーザーがユーザー名
Jason Bourneでサインアップしようとした場合、JasonBourneは既存のユーザー名であるため、ユーザー名はすでに使用されているというメッセージが返されて驚かれ、混乱する可能性があります。 ..スペースを含むユーザー名を入力した場合でも。
論理的な "自然言語のような"入力シナリオでのスペースの許可は、許可されるだけでなく推奨されます。名前は JohnDoe ではなく、 John Doe です。そして、1つのコメントが言うように（このビューに反対しようとするので、あなたはそれがどちらの方向にも行くのを見ることができます）、名前は Experts Exchange であり、 expertsexchangeではありません確かにエキスパートセックスチェンジではありません。そして、これがユーザー名にスペースを有効にする必要がある理由です：ランダムな発生の正確さと制限。 ランダムなスペースという意味ではありません。 自然言語スペースを意味します。
また、ランダム性のクリアはすべてに適用されることに注意してください。つまり、入力を二次的なステップとしてサニタイズできますが、スペースの有無にかかわらず、ユーザー名は1つの方法でのみ使用する必要があることを明確にする必要があります。友人に戻ると、彼がJohnDoeとして署名した場合、ユーザー名はJohnDoeになり、John Doeではなくなります。
もう1つ：次の条件でユーザー名をサニタイズおよびフィルタリングできます。
- スペースbeforeユーザー名
- スペース後ユーザー名
- 繰り返されるスペース
この方法では、スペースを1つだけ許可します。ユーザー名を2語に制限したり、次のようにユーザー名オプションをユーザーに提供したりすることもできます。
John Doeへようこそ。ユーザー名を選択してください
- ジョン・ドウ
- ジョン・ドウ
- またはユーザー名を入力
最後に、ケースの通常の中間点があります。1つのユーザー名/ログインを持ち、次に表示名を持っている場合があります。これは非常に一般的なアプローチであり、スペースを使用しない場合は熟考する必要があります（結局、sernameはdisplay nameと同じではありません）。私たちの親友はJohnDoeでも、johndoe69でも[email protected]でもないので、ユーザー名にスペースを使用することをお勧めしますORユーザーが選択した表示名を許可します。スペースを使用する方が簡単な方法ですが、これを行わない場合はdisplay namesを使用してください。
alterユーザー入力をデータベースに保存しないでください。 Sanitizingが一般的であり、推奨されます（たとえば、文字列の末尾から空白が削除されます）。空白なしで情報を保存しているため、元の入力を取得することはできません。また、ユーザーが（パスワードリセットの電子メールまたはアカウント/プロファイルページで）本来とは異なるユーザー名を表示すると、ユーザーが混乱する可能性があります。指定して期待しています。
そのため、開発の観点からすると、それほど強力な議論はないかもしれませんが、ユーザーエクスペリエンスに対して直感に反しています。
それは誤解のように聞こえます。
Xの人には2つの要件があります
- ユーザー名に空白を許可します。
- ログイン時の空白は、便宜上無視してください。ユーザーが空白を忘れたり、空白を入れたりした場合、忘れてはなりませんが、ログインしたままになります。
あなたが結論付けた
- 「ユーザー名は空白なしで保存されます。」
ただし、ユーザー入力を保存する前に変更しないでください。ユーザーは、ログイン時に入力するよりも、正しいユーザー名を設定することに多くの労力を費やします。そのままにしてください。 - 「すべての将来のシステムは、「ストリップ空白」をサポートする必要があります。」
番号。バックエンドは変更せずに元のユーザー名を使用します。空白はフロントエンドでのみ削除されます。 1つのフロントエンドアプリケーションのみを変更することで、その機能を削除できます。
開発者メモ
- おそらく、元のユーザー名に加えて、データベースを検索するための空白を含まない簡略化されたユーザー名を格納する必要があります。これは特別なことではありません。たとえば、ドイツでは、ウムラウトのために元の名前と簡略化された名前を保存することがよくあります。「AndréMüller」は「Andre Muller」になります。
- 新しいユーザーを作成するときは、簡易名がすでに存在するかどうかを確認する必要があります。 「JackShepard」がすでにある場合は「Jack Shepard」を許可しないでください。
あなたが本当に開発者にとって物事を簡単にしたいのであれば、すべてのユーザーに番号を与え、それをそれらとして参照するだけです。もちろん、それはユーザーにとって簡単なことではないので、ほとんどの開発者はユーザーが覚えやすい文字列を人々が入力できるようにしても問題ありません。
これは厳密にユーザーエクスペリエンスに関するものであるため、UXの観点のみから、いくつかの理由を列挙したいと思います。
1.ユーザー入力を制限するには追加の通信が必要です
あなたのパスワードが満たす必要のあるすべての基準を伝え、伝えようとするときに、別のパスワードを考え出すようにWebサイトに指示することほど、イライラすることはありません。 パスワードに特定の文字を使用できないようにすることについて同様の議論がありました と、パスワードはユーザー名とまったく同じではありませんが、多くの点が依然として適用されます。
2. 許可スペースは必須スペースと同じではありません
スペースや特殊文字が許可されているからといって、人々がそれらを使用するという意味ではありません。ユーザー名の入力をまったく禁止しない場合でも、ほとんどの人は覚えやすく入力しやすい短いものを選択する可能性があります。
3.スペースにより、ユーザーはもう少し匿名になります
すべてのユーザーが簡単に認識できるようにしたり、タグ付けしたりする必要があるわけではありません。簡単に認識されたいユーザーは、名前に特殊文字やスペースを使用しませんが、他のユーザーは「名前を難読化する」オプションを使用する必要があります。衝突を避けるために、すべてのユーザー入力が保持されることを確認してください。つまり、JohnとDoeの間にスペースを2つ追加することは、JohnとDoeの間にスペースを1つだけ追加することとは別のユーザー名です。
ユーザー名にスペースを使用できるようにすると、ユーザーエクスペリエンスが低下するのには理由が1つあります。
1.トロールとフィッシングとID盗難
アプリケーションのユーザーが互いに通信でき、ユーザー名がこの会話の唯一のIDである場合、スペースを許可することは良いユーザーエクスペリエンスとは言えません。悪いユーザーが良いユーザーを模倣しやすくなるからです。これは、ユーザー名とともに評判を示すことで軽減できますが、あまりにも多くの人が同様に信頼するでしょうJohn Doe（いいやつ）とJohn Doe （悪い奴）。
一方、アプリケーションがソーシャルではなく、ユーザー名/パスワードが単一のユーザーの認証にのみ使用されている場合は、ユーザー名またはパスワードに制限を設けません。
あなたのケースを作るのに頑張ってください！
スペース？承知しました。
とにかくユーザーの視点から。システムでスペースや特殊文字の問題が発生する可能性がありますが、ユーザーはそれを気にしません。彼らはパスワードに対してより寛容ですが、ユーザー名は彼らが制御したいものです。
変数？番号。
あなたのUX担当者は、このアイデアに少し夢中になっています。スペースは問題ありませんが、ユーザーがスペースを要求した場合のみです。ユーザー名がFire Breather、FireBreatherのような一連の文字のバリエーションを許可しません。ご指摘のとおり、そのバリエーションを許可すると、すべてのバリエーションを許可する必要があり、ユーザー認証はかなり面倒になります。
私が考えることができる唯一の並行点は、Gmailがあなたのアドレスのどこにでもピリオドを受け入れることです。これも少しばかげているようで、あまり使われません。
懸念が自動修正/提案/大文字化されている場合は、入力フィールドでその機能を無効にしてください。ほとんどの場合、とにかく無効にする必要があります。
サイドバー：ケース
私はそうします、ためらわずにケースのバリエーションを許可することに価値を見ます。私はそれが好きではありませんが、一部のユーザーはインターキャップまたはすべて小文字を使用したことを忘れています。認証中に各グリフを正規の英数字値として扱う場合、バリエーションを受け入れることができます。
スペースの数と場所のみが異なる名前は、意味的に同じ名前ではありません。 Michelle BlancとMichel LeBlancの両方がシステムにアカウントを作成したい場合はどうなりますか？
Michelle Blancがスペースを使用するかどうかを選択できるようにするだけで十分ですが、Michel LeBlancの名前を彼のユーザー名。
別のミシェル・ブランも彼女の名前をこれ以上使用できないので、もちろんこれは問題ではないと判断するかもしれません...
失敗する 最小驚きの原則 ：ユーザーは何年もの間、ログイン時にユーザー名を正確に入力しないとログインができないことを学んできました。これは驚くべきことです。この驚きは、ソフトウェアのあらゆる面で信頼性の低下につながる可能性があります。ユーザー名には「十分に近い」で十分なため、パスワードやアプリケーションの機能にも十分対応できると思います。または、これはアプリケーションでのonly "十分に近い"使用であり、さらに別の驚きが待っていますか？
あなたがしているすべてがログインフォームから来るユーザー入力からスペースを取り除くことを条件として、これは欠点のない合理的なアイデアだと思います。
すべてのスペースを削除する、ログインフォームでの即時変換以外に必要なコードの変更はありません。
ユーザーは、スペースを使用したときにハードエラーメッセージであったことを除いて、UIに違いはありませんが、フォームの残りの部分が正しい場合はログインします。
とは言っても、あまり役に立たないと思います。それは本当にマイナーです。
UXやプログラミングなど、許可されるべきではない理由はわかりません。処理する前にスペースは削除されると述べたので、これは「ユーザーに電話番号を尋ねるときに、ユーザーが電話番号に括弧やハイフンを入力できるようにする必要がありますか？」とほとんど変わりません。もちろん、その答えは、その入力サーバーサイドで適切に処理している限りです。
すでにほとんどのログインシステムで、ユーザー名がchristopherのユーザーは、ChrisTOpher、CHRISTOPHER、ChristophERとしてユーザー名を入力できます。多くのシステムは、先頭と末尾のスペースを取り除き、␣␣Christopher、またはChristopher␣␣␣␣（␣はスペース）を許可します。ユーザーが前述の名前のいずれかを入力した場合、christopherを入力したかのようにログインすることは、ユーザーにとって驚くべきことではありません。他の誰も内部ユーザー名christopherを持たないので、他のユーザーに驚きはありません。
おそらく、あなたはすでにサーバー側で何かに類似したことをしています
$username =~ lc($username); # lowercase the username
$username =~ s/(^\s+|\s+$)//g; # strip trailing/leading spaces
文字通り、変更する唯一のものは、2番目の正規表現をs/\s//gにすることです。これにより、実際にそれが簡単になります。
ユーザー入力をサーバーサイドで適切に検証、正規化、サニタイズ、エスケープしている場合（または、単純なチェックを追加する場合は、とにかく行う必要があります）、全スペースのユーザー名を入力するエッジケースは問題ではありません。 —フォームが送信を許可していないからといって、誰かがフォームデータを送信できないことを意味するわけではありません。決してユーザー入力を信頼しないでください）。唯一の真の懸念は、ログインとして電子メールアドレスを使用している場合（スペースが意味的に重要な場合）ですが、それはまったく別のセキュリティの懸念です。
あいまいさ
Helena BeckettおよびHelen Abeckettは同じユーザー名です。それは問題です。
より良いソリューション
スペースを含まないユーザー名と、スペースを含む個別の「表示名」を収集します。追加された利点：何も混乱させることなく表示名を変更できます。
ここで答えるべき重要な質問があると思います：
あなたが言及するユーザー名は自然言語でも使用されますか？
UX担当者がユーザー名フィールドと実際の名前フィールドをマージしてインターフェースを簡素化しようとしているように思えます。それが本当にそうであるならば、あなたはこれを考慮すべきです：
人の名前は、人々が日々の生活の中でそのように呼んでいるものですが、一意の識別子とは言えません。したがって、実際の名前から派生したユーザー名は、重複して取得されます。ミドルネーム、誕生年、または普通の古いカウンターを追加するなど、人々がさまざまな方法で処理する複製。
アプリケーションにユーザー名と本名の別々のフィールドがある場合、John Smithという名前の69番目のユーザーは、ログオン時にjohnsmith69と入力する必要があります（特に、 SSOを使用して）、アカウント情報を共有している場合でも、ウェルカムページに「Hello John Smith」が表示されます。
「John Smith 69」をどこにでも、空白文字または空白文字なしで見なければならない場合、同じユーザーが非常に迷惑になると思います。
さらに、実名とはほとんど関係のないユーザー名を使用することには、正当な理由がある場合があります。例えば。 8文字のユーザー名のみをサポートするレガシーシステム、メールのようなユーザー名を期待するシステム、または限られた数のユーザー名をあらゆる場所で使用することで生活を簡素化したいユーザーだけです。その人の本名をユーザー名に結び付けると、どんな形になったとしても、その選択は制限されます。
私の意見では、ほとんどの人がすでにやっていることをするだけです：
人に本名を尋ね、自然言語のコンテキストで使用するために保存します。
実際の名前に基づいて一意のユーザー名を生成し、適切なフォームフィールドに入力して、ユーザーが変更できるようにします。それがまだ一意であることを確認してくださいそしてそれはレガシーシステムとの相互作用のために十分に保守的であること。
不明な理由で入力フィールドの最後にスペースを挿入するクライアントソフトウェアを使用している多くのユーザーがいます。
このようなクライアントを使用するユーザーは、常にではありませんが、問題が発生する可能性があります。彼らは1つのクライアントでサインアップしますが、後で別のクライアントでサインインしようとします。次に、ユーザー名が間違っていると通知されます。
私にとっては、末尾のスペースを削除せざるを得ない理由です。そして、その間、先行スペースのストライプ化も理にかなっているように思えます。
ただし、フィールドを空にすることが許可されていない場合は欠点があります。フィールドに少なくとも1つの文字を含める必要があるという仕様がある場合、クライアントがスペースのみで構成される文字列を送信することは有効です。ただし、サーバーが後続のスペースを削除すると、クライアントが空の文字列を送信していなくても、最終的には空の文字列になる可能性があります。この場合、サーバーが処理を続行するか、クライアントにエラーを返すかに関係なく、サーバーは仕様に違反している可能性があります。
この問題は回避できます。サインアップ中に、ユーザー名にスペースのみが含まれるユーザーの作成を禁止できます。スペックにそれに適した単一のエラーメッセージが含まれていない場合でも、この特定のユーザー名が使用中であることを報告するだけにフォールバックできます。ログイン中にユーザー名が正しくないことをユーザーに安全に報告できます。これは、最初にユーザー名を作成しないことを知っているためです。
末尾のスペースを削除することをお勧めする場合、次の質問は、すべてのスペースを削除するように拡張するかどうかです。他の回答にはすでにこれに対する賛成論と反対論が含まれているので、ここで追加することはほとんどありません。表示される3つのオプションは次のとおりです。
- 静かにスペースを削除します
- スペースを守る
john doeとjohndoeは、2つの異なるユーザー名です。
ユーザー名がバックグラウンドで使用されているシステムによっては、スペースを維持しないようにする技術的な理由がある場合があります。たとえば、ユーザー名の末尾と他のテキストの開始位置を示すためにスペースを区切り文字として使用するシナリオがあるため、UNIXシステムのユーザー名にスペースを含めるのは非常に不便です。
それが間違っていると感じる理由は、スペースを許可すると冗長性の前提が作成され、冗長性はUXが悪いためです（エキスパートの発言に関係なく）。あなたのアプリケーションはおそらく、すでに名と姓を個別のフィールドとしてキャプチャしていますよね？ユーザーが「John」と「Doe」を入力すると、彼らはあなたに彼らの名前がJohn Doeであることを伝えました。さらに進んで、「John Doe」というユーザー名を選択できるようにすることは、彼らにとって、時間の無駄です（そして、あなたがそれらを選択することはできないので...）。最後に、「選択してください」一意のスペースを持つユーザー名」とジョンは「ジョンドウ6」を使用することを余儀なくされている彼はかなり不器用で疎外感さえ感じます。
適切な名前のフォーマットのふりを完全に無視するか、多くのサイトのように（ほとんどの人が採用すべきアイデアだと思います）、ユーザー名として電子メールアドレスを使用するだけです。
ユーザー名に関する要件はUXの問題ではないため、テクノロジー/ビジネス/セキュリティの問題です。
主に、ユーザー名は一意の識別子として機能し、単一の個人に情報を結び付け、その個人を追跡し、アプリケーションとそのサポートシステムによって正確に操作できるようにします。そのため、ユーザー名の入力ルールの背後にある原動力は、安全で効率的な方法でシステムのニーズを満たす必要があります。
UXリソースが「人間にやさしい」ユーザー名ではないエクスペリエンスを懸念している場合、それを改善できる方法は確かにあります。 。 。エイリアス、表示名、代替ログイン（「電子メールアドレスまたはユーザー名を入力してください」など）、ユーザー名の露出/相互作用を最小限に抑えるアプリケーション/サイトの設計など。
このポイントの販売に本当に問題がある場合は、スペースを許可することを示す証拠（ユーザーテスト結果、ユーザーフィードバック、業界標準、競合他社の慣行の使用など）を提供するようにUXリソースに依頼することをお勧めしますユーザー名を使用すると、テクノロジー/ビジネス/セキュリティニーズの要件に勝るまで、ユーザーエクスペリエンスが向上します。
私はDrupal開発者およびモジュール管理者です。Drupalの内部登録システムはデフォルトでスペースを許可するため、ユーザー名にスペースがないスパムボットから多くの注目を集めています。具体的には、ユーザー名にスペースを強制する。要するに、スペースを含むユーザー名は私の控えめな意見では強制されるべきです。
では、次のように、一連のスペースのユーザー名を作成するとどうなるでしょうか。私の理解では、これは有効なユーザー名です。ただし、空白を削除すると、ユーザー名はなくなり、おそらくページが壊れてしまいます。