Tag Info

New answers tagged

0

Inline hints are good because they provide context... I agree with you that inline alerts that make other elements shift causes friction and is distracting. There are ways to provide inline help that doesn't do this like making it invisible and just showing it as needed. Problems with popping up toast alerts include... It could go unnoticed It may ...


2

Let's start from the beginning: If you want to attach to the path to completion advice, you should do something like this: download bmml source – Wireframes created with Balsamiq Mockups Compare it to this: Improvements: Labels aligned with inputs => Less visual fixations, just 1 visual direction, less horizontal space, but more ...


2

Not all form actions are equal (Reset, Cancel, & Go Back are secondary actions: rarely need to be used (if at all), Save, Continue, & Submit are primary actions: directly responsible for form completion). The visual presentation of actions should match their importance. Avoid secondary actions if possible. Otherwise, ensure a clear visual ...


1

However, my instinct is that asking for such little amount of information deters users because it seems less secure or less legitimate in some way. My experience has universally been the opposite. That the more information you ask, the fewer transactions you get. At the point I have got my customer to the checkout (if I'm doing my job right) they've ...


1

Question should be "how can we improve the registration flow so that it's less painful?" rather than "can we remove the registration flow altogether?". This is because, not all companies have the same business model. Therefore the needs of each website will differ based on their business model and what services they are providing: 1. Registration is ...


1

Here are some of the things you can do to increase the credibility of your website and reassure users on the security of your checkout process. 1. Use SSL on your domain name 2. Display SSL Secured logos on your Checkout page 3. Put any other certs that your site is accredited with on the footer of your website or checkout page 4. Display your ...


0

This is difficult to test because there is very little information you can use to tell whether the users coming into your website are using strong passwords already or not. One way I can think of at least trying to work out the potential behaviour is if you can measure the amount of time people spend on the 'enter password' field before they click submit, ...


0

Anecdotally, I personally use the password requirements listed to generate the strongest possible password with my password manager. I find these very useful, and they immediately tell me if I need to turn off special characters or if I get to leave them on, if I need to reduce the length of my password or if I get to keep it long, etc. As an addendum to ...


1

This is a good UX question so go ahead and vote it up now. I believe that there is already a trend moving in this direction. Reasons to skip a registration flow are... 1. Remove Barriers to Entry Can you imagine visiting a mall and outside of each shop is a person politely asking you for your name and nothing else before letting you in? Sure it's nice ...


1

Technically, your question has many issues. Relying on cookies is a no-no, cookies are a tool, not an UX process. But more important, let's assume we can solve all the technicalities (we can't. It's as simple as visiting the page from a different device or browser, but let's say we magically can). Now you're talking on a whole different philosophy. Please ...


0

Cookies/sessions are not reliable. Nothing can guarantee that users keep them for reasonable times. Some users also have disabled cookies on their browsers. After all, I don't think we need authentication users before that really care about our products. That's a business centered approach that they want to know more about users before a real purchase. Let ...


1

It depends. In general long forms where long = lots of form fields is a bad idea and should be avoided. Splitting a form into separate pages may help in that situation. But in your case, you're using the term long to refer to vertical height of the page. Remember that people are just fine scrolling--ESPECIALLY on touch devices. As such, I see no benefit ...


0

A/B testing and Usability testing will give you the correct answer. Forms are super tricky. I am dealing with a huge/unfortunately necessary long form and I've realised A/B testing and Usability testing is the only way to find out.


0

You should consider doing some user testing on two designs: one like this and one with steps. You could get valuable feedback from testing multiple designs. If you split the form up, your sections should be very clear and distinct. In looking at your form, I can't clearly distinguish different sections. There's an "about your project"... but what category ...


0

I consider that is better to divide the screen in two steps or three, this is a very important for our users to navigate to the app. If they bored, simply they go back or close the site because the UX isn't the better. You take a look some mobile apps and inspire you in how design a web mobile app. For example, in the facebook's apps wizard we have various ...


2

Well, it's a bit of a "dirty" manipulation that could direct a user's potential dissatisfaction at himself rather than at the system :). A user arrives at page, creates an invalid password, gets an error message that says "The password must be over 8 chars". He looks for the password rules on the page. If he doesn't find them, he becomes angry with the ...


0

Rather than allowing the administrator to add, edit, and delete questions, consider allowing the administrator to add or archive questions instead. In this way, the administrator could change the questions to be displayed on the profile without the danger of creating nonsensical answers to questions. Archiving questions also provides for the case in which ...


0

WPF validation can be set up to highlight/tooltip-explain bad fields when they lose focus; that way the user's complete input is available. You can leave OK/Save disabled until all fields validate successfully, but a better approach (in cases where most/all fields start out blank and a user might forget to fill in one that's required) is to have the button ...


3

In the described scenario, you should never provide an edit option or you'll have the problem you're mentioning. Basically, you're writing to a database, so let's say I have this question and answer: Q: roses are red, sky is... A: blue And now I edit the question, effectively overwriting the database's value: Q: Your teacher is... A: blue Which can ...


0

I would use a button interface that will let you know how long I took. Its easy to know if it was more than 60 minutes, specially if it does not requires how many minutes after the 60 mark. Expanding in the subject, here is my input: Although 60 minutes time frame is a great push and pressure to complete the challenge, I think that time frame is not for ...


3

Users aren't likely to fill out optional fields. Most people's brains aren't wired to keep track of time while they're actively engaged in an activity. To have them quantify how long they spent on the project by entering a number will cause most users to short-circuit and skip that field entirely. If you absolutely don't have any practical means for ...


1

I would try to approach your question from a different angle. You should be considering what best pattern/tactic may be to solve the particular design problem. Otherwise you may be getting into the "square peg into round hole" pitfall. You may want to start by considering the mental modal and goals of the user when they are trying to complete whatever ...


1

If you are aiming at desktop and mouse, have you thought of user resizable dropdowns? Image from Google: You could even remember the last size, and let users decide the best number. Otherwise, there's no good answer to your question: it depends on the real estate of your users and how important (or distracting if there's too much) is the item ...


1

A List Box is in itself there to save space from a page, and to make it somewhat simple to select an item from a long list. I have found no recommendation on how many items to show at once. The only recommendation found is to not use a List Box when there are only two items (male/female) selection. The popular list box example is the country selector, where ...


1

Simplicity. Both in terms of implementation and in telling the user what is expected. All users will understand what it means to enter the number with all digits and no dashes or spaces. Some small amount of customers will get confused if told that they can use dashes or spaces, and then they see their card only has spaces, no dashes. Keep in mind there ...


2

Why do web designers force users to enter credit card numbers without hyphens or spaces? Laziness. In general, super-strict form field format requirements rarely benefits the end user. It's typically implemented that way due to lax parsing on the back end/status quo/low priority. Which is unfortunate.


1

The tooltip example given by W3C in this page goes: <div class="text"> <label id="tp1-label" for="first">First Name:</label> <input type="text" id="first" name="first" size="20" aria-labelledby="tp1-label" aria-describedby="tp1" aria-required="false" /> <div id="tp1" class="tooltip" role="tooltip" ...


1

If the user wants to contact you, let them in the least unobtrusive way. As such, option #3 = make it a mailto link is the one I'd push for. If you have to have a web form, make it as simple as can be: Email: Subject: Message: [SEND]


3

For mobile users, the mailto can prove to be a life saver, they can type continuously on their mobile in their native email environment (natural for mobile?) and won't have to deal with "Tap- Enter detail -Tap again to hide Keyboard-Move downwards". Here's another thread on mobile mailto vs contact form: Contact form on mobile vs. mailto: link? For desktop, ...


1

Tooltips may be visible when styles are disabled, so the first thing you want to do disable CSS in your browser and see if the tooltips are visible. One way to do this is with the Web Developer browser extension. Here is it for Chrome and Firefox. You can tab to them and see if they appear. If they are not visible when styles are disabled, make sure that ...


4

Keep in mind that accessibility is more than just accommodating screen readers. Tooltips can be troublesome in a lot of situations: screen readers (as mentioned) non-mouse access (keyboard, touch devices, etc.) dexterity challenges (the (?) icons are often very small) In general, you will want to: make the target as large as possible make the tooltip ...


2

Including an alt attribute is the first step for supporting accessibility on the web. WebAIM (Web Accessibility in Mind) has an article with several tips, Designing for Screen Reader Compatibility. Among the many tips is: Screen readers will read the alternative text of images, if alt text is present. JAWS precedes the alternative text with the word ...


0

I have heard that some people make CGI scripts 'n' such to check up/validate input in information/data fields. Surely they can make a script that will accept spaces or hyphens in credit card numbers, then strip them out for the IT folks in the computer room. This makes it easier for the user to enter and double-check his entry before hitting "submit" or ...


4

There isn't really a "good" answer to your question, simply because they're engaged in bad practice. While that sounds negative, the simple answer is that they are not considering the User Experience properly: a flaw many designers and developers have, and one which I'm guilty of displaying myself on occasion. It may be that it takes too long, that they ...


2

I'm more on board with @IgorGubaidulin's answer if it was my site, but working with what you have, I would just simply move the logo inside and be done with it: Option 1 Option 2


1

Your most common are likely to be: Full stop at end of address Commas instead of full stops Semi-colon or apostrophe instead of @ Spaces in middle or at end of address Bracketed note in field – eg. (office) Double periods.. Some common misspellings: Googlemail – Gogglemail, googlmail, goglemail Hotmail – Hotmial, Hotmal, Hoitmail, Homail, ...


0

Thanks all, after some more discussion we came to the conclusion that hitting the save button is best. One particular deciding factor was the chance to undo changes. If you changed one field and then wanted to change it back, you may have lost the original data.


1

I did a super-informal hallway study about a week ago. So, obviously not something to cite, but may give you some ideas for your own study. I asked 10 people if they found the 'remember me' feature useful in the context of a secure mobile app (context is likely key here). 7 out of 10 said they rarely use it namely because they forget to check it before ...


2

I had a project manager once who insisted that dialog boxes randomize the arrangement of the buttons so that users didn't get in the habit of just clicking through the confirmations. At first, I hated the idea, but after seeing the results, I still do it in new projects, twenty years later. Unfortunately, just rearranging a few controls is probably ...


0

Yep, they should probably hit a save button. With a lightbox, the only way of moving to the next task is by clicking the X in the corner. This is generally recognised as a 'dismiss' or 'cancel' action rather than 'save'. In a lot of cases, having no save button is likely to make the user ask "Is my data being saved? ...maybe I should look around for a save ...


3

I think most users would prefer having to press "Save". It gives a sense of control. I fail to see how this increases the user experience when using a modal window. There really is no reason not to have a "Save" button, as they have to close the modal window after they are done anyways.


1

I think this should be more specific than leaving a blank field. A blank field can get ambiguos as there can be many interpretations from the point of view of the user. I would go, as suggested by poison-ivy, with an explicit option for "no due date". Or telling the user via a tooltip, that leaving a blank would mean "no due date".


0

Since it is not a required field, it is possible that a user just forgets to enter the due date. As a user (assuming I know this), it would make me questions whether there is no actual due date or if it was just missed. If users are expected to enter a due date most of the time, I would make this a required field and have an option "no due date".


2

It sounds like the lack of a due date is a valid use case that needs to be made more obvious. It can be hard to tell the difference between "hasn't entered a due date yet" vs. "there will never be a due date." If the ability to enter things like "59 days" is not a critical feature, you can solve this problem by using a select dropdown instead of a text ...


1

As a user, I wouldn't be certain if the box should be left blank, I should enter a "0", or if entries without due days weren't allowed. I think adding a checkbox for the due date and having the due date box greyed out if it is unchecked would be the most clear. Preventing the user from making an entry if there is no due date removes any ambiguity.


0

This sounds like a "Visibility of system status" issue from 10 Usability Heuristics for User Interface Design If the field is mandatory then communicate this to the user. Note that the "Error prevention" heuristic would say communicate a potential issue as early as practicable. Now explicitly to question indicating it again, take the guidance from ...


0

A good guideline for validation is that it has to be the least strict as possible and right away. 2-steps validation as you describe combined with a very strict validation may result in the user feeling frustrated by your service. Meaning: "Make everything as simple as possible, but not simpler" A too strict validation may also reduce the overall ...


0

Would it be proper to show the validation message again immediately (since the user has already attempted to submit the form once,) or should the required-field validation remain hidden until the user attempts to submit the form a second time? I think if the user makes the same mistake again it's because your field (and the label) with the ...


1

Having validation in place to check values when the form is submitted to prevent invalid input making it to your database or whatever is always a good idea, regardless of whether or not the form was previously submitted. If feasible, validating input as the user is filling out a form (i.e. after a user edits a field) is extremely useful as it let the user ...


0

If you are thinking logic that is adjusted to heuristics, then yes, because this will make a program predictable hence intuitive. But if you mean math logic, then no, it's counter-intuitive.



Top 50 recent answers are included