Tag Info

Hot answers tagged

10

Jumping in with an answer because I've seen a really nice example of this in the wild. Hargreaves Lansdown is a UK financial institution, and here's how they do it: The idea of giving context to a user hadn't occurred to me before I saw this. In practice, I find it far faster and easier to input a password when I can see how far the requested characters ...


9

If any service can validate what the n-th character of your password is, it means that they are storing your password in an insecure format. No service should ever know what your password is, they should only be able to say whether your password authenticates or not. So you shouldn't ever ask for the n-th character of a password, and you shouldn't ever be ...


8

HSBC uses a combination of a username, password, and security key. In this implementation, you first enter your username. Next, you are prompted to enter your password and three random characters from your security key: download bmml source – Wireframes created with Balsamiq Mockups The benefit of this approach is that the password does ...


5

You should ask for the entire password, not just because it is more secure, but because users entire passwords by muscle memory, especially passwords made up of arbitrary characters, or defined by movements across the keyboard. This makes it hard for users to recall characters in specific positions.


4

forcing focus to search could have negative usability implications towards screen readers and other accessibility tools. I would suggest against it - the only caveat being if a user navigates to the page from another link which is explicitly designed to "take the user to the search page" (like an "advanced search" link - assuming you can not provide the ...


4

I would like to add to the above some technical reasons: In a form that has multiple fields, the page may for whatever reason load a bit later than when the user started to interact with fields, so when the page finally loads, you force cursor on search field while the user is typing in another field, you can imagine how frustrating that is, especially in ...


4

What you are describing is a Combobox and has been in use for as long as I can think about GUIs. The concept has gained new momentum in the web with the further development of dynamic elements and web apps – most notably google's search box with it's suggestions-as-you-type. Chrome's "Omnibar" is, basically, the same thing: It's a text field you can type in ...


3

The user should not be forced to enter a postcode. There are valid cases for wanting to find a nearby store but not knowing the postcode. For example: I'll be honest and admit that I can never recall the postcode for my office, even though I've been working there for 3 years. If I have to give my office postcode, I have to look at my business card. ...


2

In my experience, the easiest to use have had (or would have): State dropdown A field for post-code or suburb name, which figures out one from the other A cookie or similar to remember the last entered info (if it's something people are actually likely to use repeatedly) Some kind of IP-based geo-location to guess the info in the absence of said cookie ...


2

I can't say I know of any research into this, but for me this would be a no go. It just isn't intuitive enough for the user. Perhaps a better solution would be to present the user with a drop-down in the first instance, if then the user cannot select an appropriate option, reveal an input field giving the user the ability to manually enter the relevant ...


2

Whether or not you need to be able to cancel an action (edit or insert) is dependent on the consequences of the action. Does adding or editing an item have immediate consequences for the user (i.e., is business logic executed, etc.)? If not, it may be OK to leave out the cancellation option - the user can always delete the item, change the value, or go ...


1

If I understand correctly, they have to enter the digits one by one from left to right. This is bad interaction design for the following reasons: It violates the principle of least surprise. Users see a text boxe, they expect it to behave like a textbox. The conventions may not be ideal, but you have to take them into account. There's a lot of work between ...


1

Targeting specifically to your "page full of text boxes", it is (as you have mentioned) very important that you avoid such a situation. Might I suggest another approach where there is just one text box that will be used to add the nodes, and the subsequent nodes are added as text links below it. You may observe the remove icon next to every node, which will ...


1

One of the main issues would be for keyboard navigation. Many users browse websites with keyboard and not a mouse / touch. For such users there is a reasonably common standard in place in websites known as a 'Skip Link'. Sometimes these links are visible to everyone (such as in the link above) and sometimes they're not displayed until you start tabbing ...


1

The issue is not restricted to search alone. It depends on the context. Many websites with login page will have the cursor automatically positioned in the first (username) field. This plays well when you have a streamlined experience. You know what the user's next step is going to be and you are making it a smoother, faster and better experience for the ...


1

In one of the heavy applications in my company I have developed almost identical UI as you have provided. There is only one button that I provide (Add a group) which immediately shows an input field without a confirmation. To cancel, a user may press an Esc key. To save, just like you said, press an Enter key or remove focus from the input field. To ...


1

My solution would be to complete the login process in two steps. Ask the user for the username, which if correct Generate the password field asking for only password on the next screen.


1

This isn't answering your question with research and what not but how about something like this? http://jqueryui.com/autocomplete/#combobox Similar but filters down and could also accept the users unique input.


1

The best way in my experience is to do at least the following: The text should be high contrast, for example black on white (preferred) or white on black depending on your design. The text should be visually distinct from labels and other non-editable fields in your application. If your application uses a mouse, ensure that the cursor changes to the I-beam ...



Only top voted, non community-wiki answers of a minimum length are eligible