Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] Number of Password Fields to use

Expand Messages
  • David LaRue
    Hello Alex, ... We ve all seen systems that have required double entry of some field because someone thought that matching the two fields would prevent a
    Message 1 of 9 , Aug 31, 2007
    • 0 Attachment
      Hello Alex,

      On Fri, 31 Aug 2007 09:45:14 +0000, Alex Horstmann wrote:

      >Hi all,
      >
      >I'm having an interesting discussion (read: argument!) here about the
      >number of password fields to use so I thought that I'd get some more
      >opinions.
      >
      >We have a feature where users can enter login credentials for systems
      >(for example a username and a password is entered for a server which
      >is stored on our system). I am saying that there should be 2 password
      >input fields to trap users mistyping the password, the other side of
      >the argument is that there should only be one. The user can then test
      >what they have done and see if it works (our system allows users to
      >test the credentials by trying to log into the target system).

      We've all seen systems that have required double entry of some field
      because someone thought that matching the two fields would prevent
      a problem down the line. I personally prefer to avoid such interfaces
      because they are a symptom of another problem. In the case of double
      entry for a password, you are trying to compensate for the user's
      lack of being able to tell if they've mistyped a value, presumably
      because they weren't allowed to see what they were typing in the
      first place.

      My systems are probably similar to yours. Your final thought above
      was that after entry the user is allowed to test their entry to
      see if it works. This is a partial solution to the problem, but
      perhaps better than requiring a double entry system.

      I have several systems that require system names, logon names,
      and passwords to be entered, among many other types of information.
      Our system has the ability to check entry of said information
      so it sounded unreasonable not to check it for the user. Double
      entry helps with getting a consistant value, but not a correct
      value. I'd ask you to consider making the validity check for
      the user, when they change that information. If the check might
      take a very long time or not be valid at the time of entry
      you might make an allowance for that. I would also not provide
      such validtion to an open interface where feasible. We don't
      want a hacker to use the interface to find a correct user id
      and password. Most of the time we are more concerned with
      getting the user information correct and it really seems a
      waste to fail later if we could have told the user much earlier
      that a mistake was made.

      I also have one system where a user id and password combination
      is entered along with screen full of information. Since the
      application can do more than one thing at once, it validates
      the credentials while the user is entering the remaining
      information.

      >I say that this is extra work and surely it's easier to make sure that
      >the user has entered the correct password by making them enter it twice.

      I quickly mistype many things. I also seem to make the same
      transposition or ommision errors. So blind double entry systems often
      don't catch my mistakes. I'm a touc htypist though and don't hunt
      and peck, which is probably where double entry is more helpful.

      >Which side of the argument are you? Why?

      See the above. I'd prefer the system use one field and validate
      the credentials for the user. I wouldn't even let the user get
      though a system without validation if the information was
      important.

      I'd also like to make a point about validation. Presumably that
      is part of the issue here. We want valid credentials entered.
      So what is your user interface like for the rest of the
      application? Do you also not validate information while being
      entered or very soon afterward? If you also needed the users
      email address did your interface bother to at least do a
      reasonable check for the validity of the address? Wouldn't
      a consistant validation aproach be better for the whole
      application?

      >Thanks in advance for your input!

      Thanks for asking,

      David
    • Hassan Schroeder
      ... A double entry requirement will only confirm that the two are the same, not that the password is *correct*. Nor will it assure that the username is
      Message 2 of 9 , Sep 1, 2007
      • 0 Attachment
        On 8/31/07, Alex Horstmann <a.horstmann@...> wrote:

        > Not quite, you are telling the system how to connect to another
        > computer by entering a username and a password, like an FTP connection
        > for example. Our system uses the username and password to connect.

        A double entry requirement will only confirm that the two are the
        same, not that the password is *correct*. Nor will it assure that the
        username is correct, or that the username and password go together.

        I'd use one field for each. And instead of asking the user to test, just
        have the system do a quick connection test behind the scenes and
        report failure if it occurs.

        FWIW,
        --
        Hassan Schroeder ------------------------ hassan.schroeder@...
      • Jade Ohlhauser
        My 2 cents: One field. Here s the possibilities with the two field system: 1. Password is correct 2. Password is incorrect - User is typing
        Message 3 of 9 , Sep 28, 2007
        • 0 Attachment

          My 2 cents: One field.

           

          Here’s the possibilities with the two field system:

           

          1.       Password is correct

          2.       Password is incorrect – User is typing correctly but is thinking of the wrong password or does not know the password and is guessing (fields match but are wrong)

          3.       Password is incorrect – User makes a repeatable error due to a problem like caps lock being on (fields match but are wrong)

          4.       Password is incorrect – user knows password but makes a random typing error (fields don’t match)

           

          You are adding the extra input step for everyone, but only offering the benefit in case 4. And here’s the kicker, you are doubling the chances of a case 4. If the fields are different you don’t know which one, only that they are different and maybe the error was added in the second one. If they don’t match I have to re-enter both again. So I’ve typed that password 4 times instead of twice (assuming it was a random typing problem that was fixed after the first negative feedback)

           

          But here’s the biggest reason, who gets that benefit? Is it the user or the system. Are you making the user do more work so the system can sometimes do less?

           

          Assumptions: the password fields obscure the values being entered and the credentials check is effectively instant.

           

          Jade Ohlhauser
          Product Manager

          RPM Software                          
          www.rpmsoftware.com 403-475-9485

           

          From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Alex Horstmann
          Sent: Friday, August 31, 2007 3:45 AM
          To: agile-usability@yahoogroups.com
          Subject: [agile-usability] Number of Password Fields to use

           

          Hi all,

          I'm having an interesting discussion (read: argument!) here about the
          number of password fields to use so I thought that I'd get some more
          opinions.

          We have a feature where users can enter login credentials for systems
          (for example a username and a password is entered for a server which
          is stored on our system). I am saying that there should be 2 password
          input fields to trap users mistyping the password, the other side of
          the argument is that there should only be one. The user can then test
          what they have done and see if it works (our system allows users to
          test the credentials by trying to log into the target system).

          I say that this is extra work and surely it's easier to make sure that
          the user has entered the correct password by making them enter it twice.

          Which side of the argument are you? Why?

          Thanks in advance for your input!

          Alex
          __________________
          Alexander Horstmann
          Senior User Interface Engineer
          Tideway Systems Ltd.
          T: +44 (0)207 368 7326
          F: +44 (0)207 352 4922
          "What we've got here is failure to communicate."

          international-usability@yahoogroups.com

        • Baker, Lisa
          For creating the password or entering the password to validate? For creating the password in the first place, two fields are helpful so the user doesn t
          Message 4 of 9 , Oct 1, 2007
          • 0 Attachment
            For creating the password or entering the password to validate?

            For creating the password in the first place, two fields are helpful so
            the user doesn't fat-finger their intended password and lock them self
            out of the system.

            For authenticating, I agree with Jade. One field is sufficient.



            Lisa Baker
            Human Factors Lead
            LANDesk, an Avocent(r) Company
            Lisa.baker@...
            801.208.1315



            "Simplifying our customers' work"


            -----Original Message-----
            From: agile-usability@yahoogroups.com
            [mailto:agile-usability@yahoogroups.com]
            Sent: Saturday, September 29, 2007 2:54 AM
            To: agile-usability@yahoogroups.com
            Subject: [agile-usability] Digest Number 683

            There is 1 message in this issue.

            Topics in this digest:

            1a. Re: Number of Password Fields to use
            From: Jade Ohlhauser


            Message
            ________________________________________________________________________

            1a. Re: Number of Password Fields to use
            Posted by: "Jade Ohlhauser" jade@... jadeohlhauser
            Date: Fri Sep 28, 2007 9:18 am ((PDT))

            My 2 cents: One field.



            Here's the possibilities with the two field system:



            1. Password is correct

            2. Password is incorrect - User is typing correctly but is
            thinking of the wrong password or does not know the password and is
            guessing (fields match but are wrong)

            3. Password is incorrect - User makes a repeatable error due to a
            problem like caps lock being on (fields match but are wrong)

            4. Password is incorrect - user knows password but makes a random
            typing error (fields don't match)



            You are adding the extra input step for everyone, but only offering the
            benefit in case 4. And here's the kicker, you are doubling the chances
            of a case 4. If the fields are different you don't know which one, only
            that they are different and maybe the error was added in the second one.
            If they don't match I have to re-enter both again. So I've typed that
            password 4 times instead of twice (assuming it was a random typing
            problem that was fixed after the first negative feedback)



            But here's the biggest reason, who gets that benefit? Is it the user or
            the system. Are you making the user do more work so the system can
            sometimes do less?



            Assumptions: the password fields obscure the values being entered and
            the credentials check is effectively instant.



            Jade Ohlhauser
            Product Manager
            RPM Software
            www.rpmsoftware.com
            <outbind://8-000000006D3A19DA0F06154598B3B2CFA0802F620700779AD3D0551A914
            1AFC9645FA3DED8680000000098A90000CB1E603596BAEE4D856D53AC40EBE439000001B
            4E5C70000/exchweb/bin/redir.asp?URL=http://www.rpmsoftware.com/>
            403-475-9485



            From: agile-usability@yahoogroups.com
            [mailto:agile-usability@yahoogroups.com] On Behalf Of Alex Horstmann
            Sent: Friday, August 31, 2007 3:45 AM
            To: agile-usability@yahoogroups.com
            Subject: [agile-usability] Number of Password Fields to use



            Hi all,

            I'm having an interesting discussion (read: argument!) here about the
            number of password fields to use so I thought that I'd get some more
            opinions.

            We have a feature where users can enter login credentials for systems
            (for example a username and a password is entered for a server which
            is stored on our system). I am saying that there should be 2 password
            input fields to trap users mistyping the password, the other side of
            the argument is that there should only be one. The user can then test
            what they have done and see if it works (our system allows users to
            test the credentials by trying to log into the target system).

            I say that this is extra work and surely it's easier to make sure that
            the user has entered the correct password by making them enter it twice.


            Which side of the argument are you? Why?

            Thanks in advance for your input!

            Alex
            __________________
            Alexander Horstmann
            Senior User Interface Engineer
            Tideway Systems Ltd.
            T: +44 (0)207 368 7326
            F: +44 (0)207 352 4922
            "What we've got here is failure to communicate."

            international-usability@yahoogroups.com
            <mailto:international-usability%40yahoogroups.com>




            Messages in this topic (8)
            ________________________________________________________________________
            ________________________________________________________________________



            ------------------------------------------------------------------------
            Yahoo! Groups Links



            ------------------------------------------------------------------------
          Your message has been successfully submitted and would be delivered to recipients shortly.