Option 2 leaves the modified content in place and visible. It means that your users don't have to recall the data they just submitted / modified.
Inline notification (Option 2):
Does not make the user recall/remember the data.
Keeps the modified data visible, allowing the user to catch any mistakes they may have made
Keeps the state indicator ('Saved') in ...
The button should always be visible on the page somewhere and should always be clickable. It is incredibly frustrating for a user if they can't click on a button and there is no clear indication of why that is the case. You should always allow the user to click submit and then highlight all fields which are causing validation issues so the user can clearly ...
The problem at hand does not seem to be a question of correct asterisk marking rules, or a literal interpretation of metaphor behind the radio button control.
Rather, the conflict from your description appears to be this:
While the two radio button selection instances are marked as required, the requirement is already fulfilled by pre-populated selection. ...
I feel you might be coming at this from the wrong angle. A form shouldn't excite you (or a user), it should get the job done quickly and painlessly.
Boring can sometimes (usually!) be best.
You mention that this form can be accessed on mobile - can we see that?
There are some issues with your form that I can see from the screenshot, many of which are ...
Option 2 is better, as discussed by Mike M. I would actually recommend a third option, similar to Option 2. I would replace the "Submit" and "Cancel" buttons with the "Saving" message and spinner. This ensures the first thing the user sees is the "Saving" message. When a user presses the button, their eyes will linger there until something else catches their ...
I'll start by saying this will probably be an unpopular opinion because, for reasons I can't comprehend, what you've done is done a lot. My complaint is that you've made 5 text fields and 3 multiple choice questions around 2800 pixels tall.
"In reality you'd scroll the page"
I swear in a decade we'll all have 8k monitors and still be endlessly scrolling ...
Disabled buttons are not good for accessibility reasons. They only provide aesthetic value as some screen readers skip over disabled elements altogether.
Having the button fixed at the bottom of screen AND disabled? BAD, colorblind users can't necessarily tell it's disabled. Fixed position could give a false ...
Familiarity + clear state
While being an ingenious idea, the left/right click is really not a familiar behavior, which is often desirable unless the benefits that the new interaction brings in worth it. In this case I think the main problem would be the lack of a clear indication of the editing state, which is not easy to convey just with visual artifacts ...
What I've found works best for my use case is to, like @Hugo-Viallon suggests, put the spinner in the save button and disable all other buttons. After completion I show a toast if the user isn't redirected.
Without the toast I had users saving multiple times just to make sure it worked, a small confirmation helped prevent that.
Essentially, your users can either select one of your suggestions, or input their own custom name, so I'd present all of these in a single radio button list. This would present your automatic suggestions, but also communicate the option of customizing the embossing name, all while still limiting them to a single selection.
It is recommended to select a default. It is also very helpful that you already know the most popular choice, which you would obviously put first in the list and preselect.
Marking mandatory input is common practice, even for a radio selection where a default is selected and where de-selecting is not provided, and even more so if for consistency reasons if ...
The easiest way might be to provide the help text next to the label, and provide simple validation for when a user fails to input the required pattern.
I don't believe "4 digits" is necessary or common in forms requesting a full year be entered. I have commonly seen "YYYY" used in the context of years, so that should not be an unexpected use here.
I agree mostly with what @Steve O'Connor has said, but there are two things I think we can discuss further:
Hint text should be useful. Meaning that if you're going to use it, write examples instead, like: "e.g. email@example.com" in the email field.
Hint texts are extremely helpful especially when the field itself doesn't exactly explain what should be ...
Reduce the amount of choices the user has to make at the same time. The first step is to decide if the user wants a notification or not.
Change the label to make it more obvious: Send a notification to my phone when the order is ready
Only show the mobile phone input if the user wants to get a notification
At this point, you can make it mandatory to fill ...
Adam Silver has recently written an excellent article regarding multiple inputs versus one input.
While using multiple inputs can be helpful, most of the time it’s completely unnecessary and it has a number of drawbacks.
They stop users from pasting easily
They require more effort to use
They can be difficult to label ...
You should only mark the field as required if the user must inform something in that field. In your example, since the user is not required to change the value of the fields, you don't need to mark them.
Placeholder text should only ever be used to hold a placeholder value which provides an example of the data to provide. If you need to provide helper text, position it either above the field under the label or below the field. I tend to prefer placing it below the field and then replace it with error text when validating the field.
In your second example, ...
What has worked well in our company:
Next to the disabled submit button is an area that tells the user what the form is awaiting. As the form validation is run on each required field, this "Waiting for..." list gets shorter until finally it says "Ready!" in green and the submit button is then enabled.
This gameifies the form a little bit and the users ...
and welcome to the site!
"as simple as possible" is not always counted in clicks. Most of the sites use two separate (but linked) pages for signup and registering because these are different use cases.
Different data: Usually, on the signup page there's a second password field, to make sure the user did not mistype the first password. If you want to know ...
Tom, how granular does this setting have to be?
Especially for less technically savvy users, providing a set of meaningful presets could already do the trick. E.g., here's the menu for setting the alert for a calendar event (taken from Fantastical for Mac):
If you click Custom…, you get to see this:
If that doesn't work, you could simply concatenate ...
Having a title is important to keep the user informed and connected to the navigation. It works as a feedback and guides the user in moving forward or backward. In the image, the title is helping the user know that he/she has opened the right page when the particular option is selected from the nav menu.
A header is also important from accessibility point ...
You could have a variant of Option 2 :
The loading could be put on the "Save" button, as a spinner that'll replace its text. You also disable buttons.
This way you show that something is happening, and the spinner being on what was the "Save" button tells the user that something is happening. The other buttons being greyed out make it even more obvious ...
I would not do it with left click - this blocks selecting the value if a user wants to copy it.
Depending on the amount of combinations a drop-down list might work.
Or group the parameters by how they exclude each other (ie, radius, volume and surface area in one group and mass and density in another) and add radio buttons.
Most applications/websites either have an icon (often a question mark) to indicate you can hover over it (but then the hover only works on the icon, not the label) or no special formatting at all. The answer here suggests using a dotted line as well; I vaguely remember old Windows (3.x) help files working the same way.
Stack Exchange has a lot of labels / ...
From a user's perspective, it will be very helpful to provide an overview of what times are available (think also of the way many cinema/theatre sites show a visual seating plan when booking tickets). As a starting point, you should be looking for something along the lines of the following, where they can both see what times are available, and pick the one ...
The less friction you can put in front a user who wants to register with your site, the better. If your onboarding process is too complex, you will lose users.
I would get the user signed up with the absolute minimum of information necessary, then maybe on subsequent visits give them reminders to fill in the rest of the data. For example, "If you are not ...
Fixed Decimal Benefits
Reduced Input Errors
Requiring no decimal reduces syntax error handling. The input is limited to 0-9 numeric characters and delete/backspace. So you help avoid cases like “54.2.89” (multi-decimal) or mistype of decimals.
Requires No Decimal (or Comma)
Sticking to digits 0-9 means you only need to use the top row of the keyboard.
Make sure that all the fields in your accordion are closed upon error check (on SAVE button press I assume)
Display a contextual error message next to the SAVE button
[OPTIONAL] Disable the SAVE button unless all the errors are fixed
Switches are generally used when there are only one or two options. In this case, there a four options so checkboxes would work better. The options could be made more user-friendly and understandable with the addition of a verb:
Allow multiple valid answers [checkbox]
Allow multiple attempts [checkbox]
Shuffle questions [checkbox]
Shuffle answers [...