Tag Info

Hot answers tagged

52

Type of the information captured and number of fields required It really depends on the type and scope of the information you are asking for and the number of fields that need to be filled: I have tested and used this pattern sucessfuly in login and and password creation. I think because the interface is so simple and the number of fields required ...


33

There are a number of variations of the the "unmasking eye" icon but they mostly have the same issue, below are some examples: I have done some usability testing on this specific problem and many users I have tested with didn't even notice the "unmasking eye" there is also some issues with how to best convey the state of the password (masked/unmasked) ...


17

I would have to say that this behavior hinders user experience. If you've ever read Don't Make Me Think by Steve Krug then you will quickly realize that this pattern is breaking the rule stated in the title. One might ask, Why is this disabled? There is no benefit to make a user jump through this hoop. Basically what I am implying is that the user is ...


10

we often see the 'continue' button inactive I think this may be false. Read on! For what it's worth, I'm updating some old research on sign up forms for popular websites at the moment, and have found that quite a small percentage - around 5% or less - disable the Submit button (whether that's the final sign up or a continue type button) until the data ...


8

Icons and labels If I was you I would not use icons for these specific fields, Words are (generally) unequivocal in there meaning (They obey conventions) while icons and the metaphores they represent are prone to multiple interpretations. Judging from your question, Having two icons that will look quite similar (Name & Surname being conceptually ...


7

One should not disable the button Consider the situation from the user's perspective. Divide users into two groups Those that do not currently believe they can proceed, so are not looking for a way to continue Those who believe they are ready to proceed, and are looking for a way to do so. For the former group, disabling the "continue" button is merely ...


6

If you are showing all fields at once, grouping them in a way to show relationships is important. Don't forget to disable items that are not relevant given the current selection, and be sure that your input fields have units (i.e., "years"). download bmml source – Wireframes created with Balsamiq Mockups You can compact the form a bit, if it is ...


4

Yes you should give user control over the app, always! It is one of the points you check for in heuristic evaluation. I use ISO 9241-110 Ergomics standard for interactive dialog and controlability is one dedicated chapter of it. What happens, if one enters a wrong, but valid working email? How can I correct it, if I recognise the error? A Sidenote: Why did ...


4

Are your users more familiar with SQL syntax or search engine syntax? If there's a strong leaning one way or the other, there's your answer.


4

What is your interface? Are users entering SQL SELECT statements directly? If so, you should use % and _ because they're part of the SQL standard, and the user is expecting standard SQL. Are users entering search terms into an application, which is incidentally using an SQL database as its search backend? In this case, use * and ? as your wildcards, ...


4

This is one of those times where you have to balance what the user wants against business objectives. Not showing the newsletter lightbox is better for UX (no real question about that), but it's worse at achieving the business objectives. What you have to weigh up is how important those business objectives are against whether you're willing to harm the UX ...


4

This is very straightforward: you have to use the standard date picker control for each platform as outlined in the appropriate design guide. Here's Android class reference, iOS class reference, and Windows Phone class reference. If you're working on a web app, it's still better to use native date pickers to minimize user confusion and provide a consistent ...


4

This is a meta answer drawing from the diverse opinions expressed. If you want to disable the button, you should still check for clicks and give reason why it is disabled. This has two advantages: fewer errors are displayed, and if you for some reason did not previously communicate why the form can not be submitted, you can explicitly do so.


4

Usually the primary active element (in this case a 'Submit' verb button) affords the user a clue about what to do. A disabled button is encoded with two dimensions: what do do and that you cannot do it yet. While this might also be confusing it does not leave as much to mystery. It also might not appear as a mistake. The big question to ask is: Why? I do ...


3

Purely out of usability reasons you should always tell user what's wrong with the input. If the user doesn't know what's going wrong, he has to guess. Guessing on it's own is a a bad user experience because it requires effort. Additionally, the more incorrect guesses he does, the more frustrated he gets. So it's always a good practice to let user know what's ...


3

Ran into similar situation in the past. We ended up solving it with a vertical form design and placing the fields this way: download bmml source – Wireframes created with Balsamiq Mockups Vertical forms are the fastest to process if you're doing strict data entry. So if it's possible to redesign the form structure that might work. If not, ...


3

As for why SQL changed? This is just my guess select * from table The * means all columns and they did not want to use * for two things Second I think you would search for a literal * more often than % Let's say you pick % for the wildcard If they enter a * then display a warning message Reminder in productname % is the wildcard - not * or ...


3

In most cases this is not a good idea. It comes down to UX goals: The main goal of a credit card form is usually to get the user to complete a purchase. Error correction and validation is only useful if it helps you accomplish that goal. The Buy it now, Purchase it, or Complete purchase buttons are usually excellent opportunities to display a clear ...


3

Hiding the submit button is not part of progressive disclosure. The only case where a submit button is not available upfront is probably within a Staged disclosure where there are a number of interdependent steps displayed in a wizard or similar pattern and submission taking place as part of the last task in the process: see below for distinction between ...


3

By auto-selecting if there's just one option you make things significantly easier for your user. Consider the comparison (which focus on one selection): No Pre-selection, text box User clicks checkbox Moves across to text box Enters some value Validation passes / fails Form is submitted No Pre-selection, dropdown User clicks checkbox Moves across to ...


2

Invision Power Board has a dropdown next to Search Bar, it is simple and understandable. If you click on the drop down, it will give you option how far do you want to search.


2

Reddit has a good pattern for this exact problem, which I would suggest you use. I've found it to work quite well. If you're not on the main page of the site, search starts off as a simple search bar. But once it's active it expands to offer a simple checkbox to limit your search to the current section of the site.


2

We normally don't critique specific designs here because it's too specific to be of use for other people. But, speaking as a general rule of thumb, if the user will be performing essentially the same action, it's best to use the same/similar view. I'm referring to the Add and Edit. When you add an Item, you probably want to deal with its Options too. There ...


2

There are simply too many rules to validate a phone number input by a user. 1. Phone numbers are ultimately just a string of numeric digits Here is one example showing how to convert anything a user inputs as a list of numeric digits. You would want to use the raw input from the user everywhere in the UI and then also store the converted string of ...


2

Wow, what a pleasantly different experience. Unfortunately, this user scenario puts you at odds with just about every login/register experience on the web. This means you'll be fighting a unique UX battle if you don't go with the industry-standard process, which separates login and registering. As is always said, don't reinvent the wheel. I would ...


2

Last option with the checkbox is the cleanest. However, you can also drop it and just leave the input control with the guidance text to skip the field if the contract is open. download bmml source – Wireframes created with Balsamiq Mockups


2

Buttons are meant to be clicked. If user sees a button, he would want to click. Disabled button becoming active only when all the data is filled in that specific form is not a good experience. I would rather tell user ( which i do with the forms i design ) right at the beginning that all the fields are mandatory and you cannot sign up if any of these fields ...


2

On a login page, what is the order for most important fields for all the users? (Irrespective of whether they want to stay logged in or not) I think most of us would have it this way: Username/email Password Login button Keep me logged in option Now going by this order, it won't make a good UX (or even pratically possible) to have a 'Keep me logged in' ...


2

This is a well known design pattern. You have a form which contains sub-workflows, which can be fired off at different times in different orders. Problems: Legends (asterisks in your case) should be avoided if possible, because it forces the user to dart around the screen to figure out which controls are asterisked. Having the action buttons in a ...


2

It'll be hard to suggest how to consolidate two interfaces without seeing them first. Your question is a bit more of action consolidation - to which the answer is yes, this is possible: You can provide a two column view, one for users one for groups, multi-select list in each, and allow drag & drop between them, both ways. Something similar to this ...



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