I suggest displaying the button in its disabled state and adding a tooltip explaining why it is disabled and how users can get the permissions to use this action.
Not displaying the button:
Users will search for this option and will maybe think they don't see it and therefore may spend time looking for it, possibly refreshing the page, restarting the ...
tl;dr → use familiar patterns
Make the text objects look less like navigational tab controls.
The elements seem unnecessarily divided: Place the search field in the main header.
Make search look more like search.
The subconscious factor making your test subjects want to tap those text objects is positioning. They appear to be tabbed ...
Well, since people are trying to interact with this information, I'd use it as an advantage. As mentioned by Mattynabib, it really makes sense.
However, if for some reason you prefer not to, the answer would be to make this snippets of information a homogeneous message. The way it is now, it looks like a mix of a marketing and an interactive element (hence ...
Type of the information captured and number of fields required
It really depends on the type and scope of the information you are asking for and the number of fields that need to be filled:
I have tested and used this pattern successfully in login and and password creation. I think because the interface is so simple and the number of fields required ...
From your description, I think the answer is pretty clear. I get your concerns about some users' expectations but this button shouldn't be shown for a few reasons.
A disabled button will only generate negative cognitive load for everybody.
Users will look at the button and think about what it does, how it's disabled, and how to enable it. You're saying ...
No, it would seem not, as W3C states
1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:
Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
Incidental: Text or images of text that are part of an inactive user ...
I do work on a professional webapp for visually impaired, screen reader users.
We do user testing regularly, and this has been raised many times during user test sessions that disabled elements that are required for completing a step/ flow (or are just generally too important to be missed) should be focusable with TAB key.
If disabled buttons are not ...
The grey text actually makes them look more clickable as they stand out from the rest of the header. I would change them to the same color as the rest of the text (black).
Also, instead of "6 books Listed", I would use "Books Listed: 6". The colon subtly implies, "here's info" rather than "I'm a link".
Is user likely to be aware of functionality?
Can an inexperienced user gain experience and then get the close privilege?
If yes, hide the button.
A button is extremely interactive element of a page. Consider these examples-
In Facebook, if you open a post in which you can only share, like and comments option are not displayed at all. Even though one can ...
I would have to say that this behavior hinders user experience.
If you've ever read Don't Make Me Think by Steve Krug then you will quickly realize that this pattern is breaking the rule stated in the title.
One might ask, Why is this disabled?
There is no benefit to make a user jump through this hoop.
Basically what I am implying is that the user is ...
If they want to edit it, they have to either ask for permission from the owner or start afresh by creating their own item.
If I understand it correctly, the only way to edit a particular item is to ask the owner of the item for permission (the other choice does not apply to the item in question).
Why not write it instead of showing a disabled edit button? ...
we often see the 'continue' button inactive
I think this may be false. Read on!
For what it's worth, I'm updating some old research on sign up forms for popular websites at the moment, and have found that quite a small percentage - around 5% or less - disable the Submit button (whether that's the final sign up or a continue type button) until the data is ...
Generalising between platforms I would go with the following basic guidelines, they further emphasise a disabled field with a grey background.
Normal (with a value)
Black text, white background, black border.
Normal (with a placeholder)
Grey text, white background, black border.
Grey text, slightly lighter grey bg, grey border.
This is a bit of a tricky one.
Normally, with regular form elements, it would be best to fully remove anything you can't interact with or serves no purpose.
However, that particular button you're talking about (the "next step" button) can also act as a guide to the level of completion - i.e. you are not able to proceed to the next step until the form ...
I would do something like
Preview: I think play is not common and clear icon for preview. Eye / magnifying glass is a bit better, but still not perfect.
Disabled button: you shouldn't hide actions behind covers / clicks; you can present it immediately. Wording and spacing might need adjustment (in your example I would also put icons closer to the button ...
One should not disable the button
Consider the situation from the user's perspective. Divide users into two groups
Those that do not currently believe they can proceed, so are not looking for a way to continue
Those who believe they are ready to proceed, and are looking for a way to do so.
For the former group, disabling the "continue" button is merely a ...
One massive reason for disabling (with explanation) the button rather than hiding it which has not been mentioned explicitly is that an experienced user will at some point end up using an inexperienced user's account alongside them.
I commonly have a similar issue with a product we use internally that hides an admin button when being used by people with ...
It's a matter of relative 'clickiness' as well. Make the unclickable items less clickable by making the rest more clickable. The phrase here is: 'affordance'.
the position of the three not-clickable items is very prominent: in your design, it's in the center of the page and it intregrates with the logo and the pay-off. That gives them a strong click-...
As a marginal counterpoint to @Leths, a screenreader lets you get to every object on the page, whether disabled or not, unless they're specifically hidden from the screen reader using aria-hidden=true. I didn't want to add this as a comment to @Leths' posting because this is an important point related to the main question. That is, even if you decide not ...
What can I do to make these three pieces of text seem totally unclickable? They're already grayed out as you can see.
In the olden days there used to be a standard that clickable text (a hyperlink) was underlined. And another one that grayed out text was inactive. How far have those standard been violated? Look no further than Stack Exchange itself:
The main driving force should be user expectation.
If the button is about a functionality that a user might expect to have, it should be there and the disabled state make it clear that it is not available (a hover tooltip can explain why).
If, however, it is a functionality that the user with the reduced access rights would not expect to have or see (or ...
In most cases, forms are made of native elements and the look and feel is therefor (ideally) determined by the operating system. Mac OS has a different way of showing something is disabled if you compare it to windows. Here are two text fields of Windows XP and Mac OS X with native behavior:
I would advice you not to change this behavior for several ...
I had a problem like this recently.
The answer I came up with was this: Elements/controls must be contrast compliant when disabled as this provides vital clues to the user telling them that their task is incomplete or that certain options are selected/deselected. - In short: Yes, they need to be contrast compliant.
EDIT - The following is incorrect however ...
Some things I have seen done before in this scenario:
Make placeholder text green instead of grey (user input is in black)
Placeholder text is in italics (user input is in normal text)
Put angle brackets around text, eg. < your name here >. (This one is somewhat "technical", i.e. something a programmer is more likely to understand)
I would suggest that ...
You should not show controls to the user if they can not interact with them. It will cause problems like frustration, doubts and may be even leaving the process altogether.
If the user finds a control that he can't interact with, first is going to look for an explanation of why. Once he doesn't find that answer, he may feel that missed a step before, and ...
The basic rule I recommend is use disabling when a command is currently not available but the user can do something pretty obvious to make it available. I think that fits your situation here. Presumably you have some indication whether each survey is submitted or not (users will need this to know which have been de-submitted and need re-submitting. If all ...
This is a meta answer drawing from the diverse opinions expressed.
If you want to disable the button, you should still check for clicks and give reason why it is disabled. This has two advantages: fewer errors are displayed, and if you for some reason did not previously communicate why the form can not be submitted, you can explicitly do so.
My short answer is no. Grey does not always represent disabled condition. I think it depends on the usage, context and the colour scheme of your app.
Lets take email sign up popups as a first example. You land on some news website and immediately after the page loads you are presented with a popup with couple of inputs and usually two buttons, Cancel and ...