Add the same text as a small label near the disabled button.
This won't rely on any on any additional user action in order to show this additional information, which is good, because users tend only to scroll and tap when using touch screen devices.
This pattern is also not a bad thing to do on desktop also. Personally, I don't usually expect a disabled ...
Your question revolves around signifiers for a button's design (i.e. hints that communicate what an element can do/how to interact with it).
I assume your primary concern with buttons is that many of them are becoming flat, borderless areas of text or icons, which often lack many of these important signifiers that indicate clickability.
There has been a ...
Don't rely on color to differentiate between hierarchy of action types.
Your current system relies on a single shape, with tone as the differentiating factor. This doesn't account for color blindness, screens with poor color, contrast issues and low resolution.
What you're trying to do is to teach users about the importance levels (or consequences) of ...
First of all, lowering the opacity makes them look disabled. So I would suggest you don't do that, as users might think that they can't complete those sections, even if they wanted to.
Using a tick/check icon for ones that are not complete is very misleading as it suggests the user doesn't need to do anything. I understand they are optional and technically ...
Do not disable buttons.
Disabled buttons predate modern touch screen usage and don't work in this environment.
For the 'I agree' or 'I have read' required checkboxes, when there is only one:
Simply put all the text on the screen. The users will see it's a TOS screen, see the scrollbar and will scroll down. At the bottom of the screen, await them ...
According to the article published in NN/g:
Selecting a precise value using a slider is a difficult task requiring
good motor skills, even if the slider is well designed. If picking an
exact value is important to the goal of the interface, choose an
alternate UI element.
Also, using a slider for a questionnaire is not an established pattern. I ...
I think you need to decide on just 2 types of buttons here to start with.
A primary button which would be a prominent color
A secondary button which would be a more subtle color
Most UIs would essentially have 1 main action which the primary button would be. Any other action could be a secondary or smaller button.
When choosing colors also consider how ...
There are a lot of individual points to make here so excuse if I just give the "broad strokes" of an answer.
Firstly "click here" - please never do that. Screen reader users may navigate your website via links and so the text within them needs to be descriptive.
Either change the phrasing or change it to "click here to get ...
Yes, remove the dialog box altogether. Users are conditioned to not read them.
Take them directly to the results page with proper pagination (loading a few results per page). If they need finer control over results shown, provide the dropdown option to choose how many results per page to load.
I'm expanding my comment on maxaathousand's answer as requested and have added some additional insight:
The most important visual key to a button is contrast (see what I did there?). This refers to:
The button contrasting against the background behind it
The button contrasting against surrounding elements and the whole page
The text or symbol within the ...
Since we don't have any visual mocks to go by, here's a quick thought on your question; I'll adjust my answer if it's off the mark, or you provide more details.
Starting an interaction:
Add or + Appointment is a fairly standard pattern for creating a new instance of an object (in this case an appointment object).
Ending an interaction: Save or Save ...
You feel "uncomfortable" when observing an input looking like a button, right?
In HCI they explain it with The Least Astonishment Principle (Wiki).
The principle of least astonishment (POLA), also called the principle of least surprise applies to user interface and software design. A typical formulation of the principle is: "If a necessary feature has a ...
Mixing Everybody's good ideas into one answer for your situation: Little real-estate on a device with no hover capability.
User @Evil Closet Monkey was on the right track: why isn't it obvious? Good design involves minimizing "cognitive load", so as a general rule you should ask yourself why it's not already obvious to the user. More specifically:
Short answer is that I don't think it exists because it is a redundant design pattern due to the history of skeuomorphism in interface deisgn.
I am curious as to whether this type of design pattern is still used these days, as it is probably a type of skeuomorphism that tries to mimic the behaviour of something like this in real life called a ...
There's a similar situation at the Github Issues report, where there's a SUBMIT button and a field to write the issue, but instead of having the PREVIEW as a button, it's a tab:
With this the CTA buttons will be just SUBMIT and CANCEL.
If this is a Modal or a Pop up window, the CANCEL button is unnecessary as such, the X in the upper right corner is ...
It can be solved for mobile devices and non-visual users (because what you propose is actually problematic for them too, as screen readers will interpret it incorrectly) using two simple steps:
Offset from the button but next to it and in it’s own HTML element (probably <div> or <span> in most cases), add a dedicated description of why the ...
Most designers think that greying out is always the best option for the disabled state of button. However, this approach often catches users off-guard because of the button’s enabled state looks nothing like the disabled one.
Let's understand first the purpose of disabling the button
Inform user that it won't work purposefully
Should not be ...
Since your default (assuming based on your domain knowledge) is that all statuses are the useful norm, unchecking one will make that the only one NOT selected, and you can change the All Statuses to the semi-selected state:
If your users are accustomed to the gmail pattern, here's how it works in sequence by clicking the 'Select All' master checkbox:
I would probably go with option 2 just because that's going to be what the user's are most familiar with. If you want people to notice and take action make sure they're a color that stands out verses the rest of the design. Adding a slight animation or having them fade in will also trigger an action.
Signup/CTA buttons are typically in the top right with a ...
Reducing the opacity on hover, when done carefully, can deliver good UX. I believe the intention behind reducing opacity on hover is to make the buttons appear brighter. But changing only the background color signals disabled state. This can be corrected by making text and/or border darker at the same time. We're essentially increasing the overall contrast ...
You are correct that reducing opacity conveys a disabled state. Hovering should make a button appear more clickable, not less.
If you want to convey a hover state with color, try the opposite -- aim for slightly increasing intensity. The normal-state button should look normal (not disabled) and its hover should be slightly more saturated and darker. It can ...
It's subtle enough to be confusing, but the button in the "Don't" example has elevation, so it's a Contained button with a white background vs. an Outlined button.
A Contained purple button next to a transparent non-elevated Outlined button is allowed.
Firstly with the state changing I wouldn't worry about the button being in the same place. The user is performing a different action in both instances so will likely expect there to be different consequences.
There are 3 options you could go with for this.
Which from what I understand is fairly similar to what you have already.
Replacing the ...
How do you see the current approach negatively impacting the user? If you were to leave it as is, would you be concerned that someone would be confused by what the "Save" button does, because of its similarity to the "Submit" button? And if after hitting the "Edit" button they were to click the "Save" button, when they actually thought they were clicking "...
If < means closing the modal (as well as x button), the 1st option is OK, as it is commonly accepted to be there. Otherwise, if it is intended to be a "go to previous step", I would say 2nd option.
In case of "go to previous step" meaning of <, I would make the button look like < Previous Step.
The "reset" button, could look some ambiguous. Does ...
This is essentially an animated overlay that protects an interactive element from accidental use. While it is rare to see it on a button, it used to be fairly common on video player elements. Somewhat like the "play button" icon that lays on top of a video and only when a user clicks are they displayed with the actual video controls to interact with; like in ...
Consider completion/progress interfaces. One example are language learning applications such as Duolingo, where progress is displayed and the completion of the task is highlighted.
Another example is Treehouse, where all the interface is laid out in a progression style. Mimicking the progress of the student across each lesson/stage.
Trying to figure out how a third state would totally impact the context of liking here. As a user, I would initially assume that the like (or heart) icon insinuates an action, especially in this social scene. This affordance is more obvious with the outlined icon as seen in scenario 1
Note: this started as a comment but was getting too long. Also, in hindsight, my answer is probably getting way off track with what you asked... sorry :)
I am going to guess that your 3 states mean: "none", "like" and "love". Where the yellow icon is used for "love" and the solid white is for "like". The ...