Redirection: should I redirect, and if so, where?
In general, no.
Not unless you're pretty confident that you know where the user actually wanted to go (and in most cases, you won’t). It’s better to give them the explicit error message, and let them decide where to go next.
If the user is trying to reach an old URL which has been moved, it's ...
Include the 404 — problem solvers will appreciate it
There’s no better or more concise way to communicate the nature of the problem to experts who may have to help your user.
“404” on your error pages is not harmful
Just to get this out of the way, including the error code is not bad, confusing, or annoying. If it were, major web companies like Google and ...
The first problem with having multiple 404 pages, each dedicated to a particular area is that you assume users were in the right part of the website at the point when they fell on to the 404.
Bearing in mind that many links come from search engines and not necessarily from within the website, then I don't think you can guarantee that a dedicated 404 is ...
TL;DR: Don't disable the submit button and wait to present errors until after the user has hit the submit button.
Studies have been conducted showing that users tend to complete forms in full before fixing errors, regardless of error presentation.
One such study looked at how users reacted to different error presentations: Usable error message presentation ...
I'm not saying it's perfect, but we launched a new 404 page this year and we included options asking people to give us feedback when they find a broken link.
Consequently we get a few emails a week which are helping us tidy up our site and fix problems.
We also included an obvious search box to try and help people find what they were looking for. We're ...
In the end, both ways lead to the same result. Whether it's an inline error or maybe a bubble with feedback, the user gets to know why he can't proceed (which adheres to visibility of system status).
The point about disabled elements never having an action is understandable, but strictly clinging to this rule is not really of service to the user. If he ...
404 and 500 are most common error codes and 404 is the most famous one. If your target audience have exposure to computer as educational basis or a mid level surfer he/she will understand as what 404 means and not much of other status codes. Still it is not a good practice to display error codes as only or prominent way of communicating technical problem/...
I'm not sure what your tech stack is, but you could use an input that the Return key quickly turns it into a taglike pill.
Here's a bootstrap example showing this with accompanying code (It's a tiny bit buggy as you'll notice the input shifts to the left a very small amount, but it's a starting point):
Users can make hard to read numeric strings into ...
In this case since the user has tried to upload an invalid format, regardless that it is optional, it counts as an error.
Warnings and Errors can be defined as such:
WARNINGS should appear when users are about to do something that is destructive or when the result of an action is unexpected, but isn't an error.
ERROR messages are used to inform ...
Error information should be tailored to the audience that needs to take action on the error.
If it is the user, the user needs to get a user-friendly or at least
user-understandable accounting of what the error is and what is
expected of him. Nobody would expect ALL users to know what "404"
If it is the systems administrator, or the network people, ...
Treat a 404 page like an error message, which it basically is. A good error message offers the users way to overcome the problem. In your example, a 404 for meetings could offer possible matches for meetings, a 404 for recordings could offer recordings, and the same for documents. The possible solutions are different for each type of entity, and the reasons ...
1. Internet connection errors that appear when opening the app for the first time
My proposal is to handle these errors with error screens (most of the apps that I benchmarked are doing ...
Since the validation is for two fields they should be marked together. I prefer, when the UI says what's wrong. So I sugest to have a message below the validation like "Please fill in either a city or postal code". Something like this:
The highlight should only disappear, when the conditions are met.
If this weren't mobile, I'd say it would be better to have a message shown next to the disabled button saying
Please fill in the remaining required fields (marked with *)
or some such (wordsmithing required).
But for mobile, where you don't have that real estate, having the button active (not disabled) and having it tell the user what fields they still ...
Looking at your form, I have a couple of concerns about your feedback mechanism
You are relying too much on color to communicate content or feedback and a colorblind user might not be able to see the difference between the two forms and might wonder what is the error is. I just ran your "error image" against a color blindness checker and in two types of ...
Yes, it’s a good idea.
Especially if you notice that there are some misspelled links out there, e.g. if someone links to your login page with /login. instead of /login (because the URL auto-detection of their CMS thought that the dot for ending a sentence belongs to the URL).
Preventively adding such redirects is probably not of a high priority, however, ...
As you say "I don't think the average user knows or cares what 404 signifies" so it doesn't matter to him.
But to the technical user the 404 gives extra information.
So if the decision is between displaying and extra sentence or not, displaying it gives some information to a minority of users, while it doesn't bother the majority (average user).
Taking limitation into account: plain html input (no colors, no tokens) I would suggest to:
Increase field size from 20% to bigger value because user will not be able to see entire value of the input in edge cases;
If "on type" validation is acceptable when delimiter is detected then do a validation and show error message: "'incorrect_value' is invalid". ...
I always appreciate a witty 404 page since not only does it convey that the Page Does Not Exist but also contributes to an experience that relates to your brand.
For example, I am a Part Time employee at Haptik and they have the No Calls, Only Text approach to improve Customer Service.
Hence, here's what they have done to theme their 404 page:
This is how the Google sign-up process does it. It should be very similar to your process. Note that the primary button is always enabled, it only changes its function!
You are presented with a pretty self-explanatory form
The Next button has the primary color and can be clicked. Note that the secondary button takes you to a completely different process (...
I'll answer your question in reverse
Which form is best for android users, a dialog message, a toast message or something else?
To answer this you will need to understand what a toast message is used for and when do you use a dialog message.
A toast message is used to give a notification about some event or activity which is not critical and needs user ...
Short answer: yes.
Extended answer: Yes and no.
The main problem here, which I think has been made clear, is that for you to identify all of the possible mistakes (which is hard to plan for) and redirect them all is more effort than it's worth (unless you're Google, but even then...).
An alternative solution would be to create a 404 page that offers ...
I'll try to improve on the suggestions by illustrating the error scenario and suggesting a different form layout.
The fieldset is appropriate when the fields are related. In this case the mandatory nature of the last name, city or postal code creates the relation. The first name comes first as it is logically tied to the last name field but stays out of the ...
If you want to show only one error;
note: I wouldn't recommend this option, it removes a lot of important information.
Show the first error the app encounters. That way users can chronologically try to fix things. It also prevents showing dependent errors. For example: you need a http connection to load an element, but you don't have an http connection, so ...
You can't show a numerical value because that would imply a value, which is a wrong value by definition.
I'd better say you would display a message saying something like "error getting number" with a link to why there may be the error.
Yes you can, but it will not help you much.
What you need is information on what was happening when an exception was thrown in your code. In many cases, users can't even provide you the information you need, because they have no idea what is going on in the code. In other cases, they do have relevant information (e.g. what they were clicking when the error ...
In 1999 it was 1 in every 26 customers according to the article: http://www.adrianswinscoe.com/not-many-complaints-but-still-losing-customers/
In my opinion a "typical" proportion of people who complain cannot be measured. It will depend on many factors, such as the audience's demographics, type of an application (crucial vs nice-to-have), etc.
Place the error next to the field
Tables often have many elements, so the easiest way to communicate an error in the table is to place the error message right next to the offending element, so that it's very clear to the user where in the table she should focus.
I would use a mix of your options:
Show an inline validation and don't disable the submit button.
If the form is still invalid when clicking submit you could auto scroll to show them (if they've get "out of the screen") and show the errors below the fields until each field is modified. This approach is currently used by Google, Facebook and Twitter.