Tag Info

Hot answers tagged

50

So basically you want someone who signs up for a new account and enters already existing credentials, to log in as the owner of these credentials? I wouldn't recommend this: The chance that the person signing up is not the owner of the existing account may be small, it is still possible. The difference between signing up and logging in should be clear. A ...


33

Yes, log the user in There are several ways an existing user might end up on a sign-up page: User clicks sign up by mistake User recently signed up for an account and the browser URL autocomplete takes user back to that URL (most recent) User forgot they signed up previously and is attempting to sign up again (and, like many users, ill-advisedly uses the ...


32

NO. There are chances that user might have no idea about their registration status on the site. And start a fresh registration. In such a case, best solution would be to OFFER a way to login by inline validation. Before the user reaches the password field, the validation should suggest ways to login as the email is present in database. But, since its not ...


27

This is a very common situation with client-side validation In a world with no budget or time constraints, yes...of course users would be better off with more information. In the real world, you probably have far better priorities. The only time when users would see a server-generated form error is: (a) if your client-side JS is broken (in which case, ...


27

@Mayo has, I think, the answer with the clearest affordance. But, if the discount field is going to be used frequently, an approach that has been proven to work with many professional and productivity application is the polymorphic input box. Applications like Microsoft Word, PowerPoint, Photoshop, AutoCAD, Illustrator, and others use these boxes ...


26

I disagree with the other answers, and say yes, it may make sense (with a couple of caveats). There is an increasing prevalence of the combined login/sign up form pattern on some sites, where the whole sign up form is simply email address and password, and all more substantive profile questions become an optional step after registration. This pattern ...


18

You could use a toggle switch ABSOLUTE | PERCENTAGE and have the user select which one he wants to use. For example: (don't mind the $ sign I did it quickly) and let the user select between the two options. This format works very well in use cases that I deal with. Buyers and bidders have to make numerous (100+) decisions in a day. It's easy to select ...


13

Nested blocks in a vertical layout This pattern tested very well with our users. It uses common language to explain what you are looking for and allows any level of complex grouping where individual blocks can be moved around, changed from AND to OR, or deleted. This level of clarity does take up quite a bit of space but not too much for most simple ...


12

Yes, you should provide server-side validation along with client-side validation Client-side validation allows you to provide feedback as quickly as possible. Immediate feedback allows users to identify and fix common errors without having to submit the form to see the errors. Server-side validation messages provide a backup communication tool. There are a ...


12

Show all items on a single page in a vertical list This obviously has limits as it is almost never a good idea to display thousands of items at a time. Though putting a list of a hundred items on a single settings page is fine especially providing some way to quickly filter the list at the top. Chunking them into groups as you have done is a good first ...


9

Separate the UX from the implementation concerns This will help simplify the problem by clarifying priorities and through decomposition. Usually, the first priority with a complex form is to design the optimal user experience. UX makes a huge difference with long forms, so that's why it helps to separate the concern and focus on creating a clear user ...


8

I'd be inclined to say present it as a whole page (your option 3). With a caveat...that you present it in a way that doesn't feel like one long page, but a collection of things. You say you worry about it being overwhelming, but it doesn't have to be like that. Provided you chunk the information well, making the headers and titles clear (but not shouty), ...


8

Observations It's hard to answer this without a better understanding of what style constraints you're facing, but: Account information is related, so I'd be inclined to keep it on one page if possible. The principle issues with long-page data are user orientation and navigation. Field layout is secondary to those concerns IMO. As a result, typical UX ...


6

Users First you need to know who are the users and if this approach fits their needs and skills. For most business users and/or logic is hard to understand and should be avoided. Technicians or clerks in finance, accounting, ... are used to such a logic. UI Depending on the requirements several implementations are conceivable: Simple filter: Implicit ...


6

I recommend Gustav's option #2. You can give both, allow both to be editable, and have the counterpart update to reflect the change, either as they type, or upon the input field losing focus. This would also take care of the need to round. I could type 20% for the discount, and then tab to the absolute input field and round to the nearest dollar. In cases ...


5

Use specific math symbols, not para-math or pseudo-programming. Some part of your users may not be familiar with math, so provide a description next to symbol. Group similar symbols (less & less or equal) into pairs. Consider using "belong/not belong to set" instead of "between".


5

It's best not to reload during a signup process, but sometimes it can't be avoided. There are many signup processes for even very mature sites (e.g. gmail, ebay, etc) which involve page reloads. What issues need to be addressed? Page loads create cognitive disruption to users. While you're filling in a form, the page becomes your universe so a reload ...


5

From comment and reply above: If a user must go out of his way so as to pass client-side validation but fails server-side validation as a result of putting javascript in a field then we're truly talking about an edge case. – Mayo @Mayo We are. And that's why I'm asking if it's really necessary to provide detailed errors in such a scenario. – ...


5

I like Googles vision on this. The user should always know what the input field means, even when a user is focussed on an input field (and the placeholder disappears). Take a look at the material design guidlines: http://www.google.com/design/spec/components/text-fields.html#text-fields-multi-line-text-field I also like this tutorial about floating labels: ...


5

The answers so far all focus on ease of understanding. This is important, but if the tool will be frequently used, ease of use is also something to consider. If the typical user is likely to use this feature many times, I would let the option be set by typing % or a currency symbol directly in the field along with the value. This will allow an expert to ...


5

I would not recommend that. Signing up screen should inform visitor that a certain email is already registered. When you inform the user about that, he/she takes a step back to remember when and what he/she did that. This helps him/her get into context about the last visit to this site. Your website should comply to user's mental model. I do not think every ...


4

If I understand you right, this is an app for the teacher, to record attendance of students at each lesson. Put yourself into the teacher's shoes (or better, interview a few teachers) and think about the entire process: What is the teacher's motivation? A requirement by the school? The need to factor attendance into grading? You may identify ...


4

What are the user needs? Based on the information from your questions I would also go with 3) and I'd like to mention 3 points: Long pages using a scroll bar is widely accepted UX Myth #3: People don't scroll Make the content sexy: use images, categories, charts, comments, ... Whatever is possible. Make it more comfortable for the user. E.g. a fixed index ...


4

IP is, though, a good start. Using HTML5's location abilities is a good idea. What you are considering is something many sites have already figured out. I'd start by seeing what the other's already do. Look at large retailers with web sites that offer in-store pickup. Home Depot, Target, Walmart, etc. Ideally, you let people search everything and only ...


3

You are describing a use case for an expert interface Expert interfaces are specialized to accomplish a particular task effectively. The UX trades off intuitiveness in favor of productivity/accuracy/speed. Here's an example of an expert interface, a stock trading keyboard: Unfortunately, expert interfaces are so specialized that they aren't very well ...


3

I see 3 options: 1: The switch. download bmml source – Wireframes created with Balsamiq Mockups Use common symbols like $ | % 2: Show both. 32.43 (0.64%) 3: Take over responsibility. And decide what's the best for your users. Ask what they want to see, why they want to see it. Marketing purposes: go for the one which suits better ...


2

Simply, yes. Why wouldn't you provide the user with as much information to rectify the problem, that they need?


2

Use HTML type="tel". Read about it here The Idea is to have something like this setup _ : _ So the amount of keypress/touches will be 4, ex. 12:45. I would try to make them go with always using 24-hours, to save space and bring some kind of consistency into it. Presets as mentioned @tohster is a good idea, like :15, :30 and :45 on buttons to save a press. ...


2

Yes, you should give specific error messages! In a perfect world, errors would never happen. Unfortunately, we do not live in a perfect world. Errors can happen, and let me tell you that by far, the most irritating thing to come out of an error is a generic message such as "An error has occurred!" The one product that I've seen this happen the most in is ...


2

From a UX perspective, there are things that could be done to help the user experience by not setting pointer-events to none. Showing disabled fields to a person is sometimes cruel. If the rules for why the field is disabled are complex and not obvious from the screen layout, it is like holding a carrot just out of reach of the person trying to use the ...



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