2 missing word
source | link

As with so many questions regarding UX, the answer starts with 'It depends'. This is because UX is inevitably based inon context and action.

Some arguments for using a disabled state:

  • Even if not in use, the user has a chance to learn that the action is possible. You may even have a tooltip explaining the criteria for use.
  • The user can learn where controls and buttons live within the interface. This assumes that if a lot are hidden at one time the structure would be less clear. (Depending on your design).

Some arguments for hiding the button:

  • Clarity. Only showing what is needed for the task at hand. Attention is focussed.
  • It allows you to change the controls, using the same space for different means. Gmail does this. This is handy when there is a lot going on.

The questions you should ask yourself are

  • "What does the user need to know at this point?"
  • "What does the user need to do at this point?"

Remember that no screen is in isolation. Each frame helps tell the story. So if you can establish an idea or pattern previously the requirements for this screen may change.

While simplicity is a great goal (potentially supporting not showing the button) you should never simplify more than necessary. Therefore if the user needs to know about the existence of the button, or you need to build the context, you might need to consider it.

A good testing regime should tell you this.

As with so many questions regarding UX the answer starts with 'It depends'. This is because UX is inevitably based in context and action.

Some arguments for using a disabled state:

  • Even if not in use, the user has a chance to learn that the action is possible. You may even have a tooltip explaining the criteria for use.
  • The user can learn where controls and buttons live within the interface. This assumes that if a lot are hidden at one time the structure would be less clear. (Depending on your design).

Some arguments for hiding the button:

  • Clarity. Only showing what is needed for the task at hand. Attention is focussed.
  • It allows you to change the controls, using the same space for different means. Gmail does this. This is handy when there is a lot going on.

The questions you should ask yourself are

  • "What does the user need to know at this point?"
  • "What does the need to do at this point?"

Remember that no screen is in isolation. Each frame helps tell the story. So if you can establish an idea or pattern previously the requirements for this screen may change.

While simplicity is a great goal (potentially supporting not showing the button) you should never simplify more than necessary. Therefore if the user needs to know about the existence of the button, or you need to build the context, you might need to consider it.

A good testing regime should tell you this.

As with so many questions regarding UX, the answer starts with 'It depends'. This is because UX is inevitably based on context and action.

Some arguments for using a disabled state:

  • Even if not in use, the user has a chance to learn that the action is possible. You may even have a tooltip explaining the criteria for use.
  • The user can learn where controls and buttons live within the interface. This assumes that if a lot are hidden at one time the structure would be less clear. (Depending on your design).

Some arguments for hiding the button:

  • Clarity. Only showing what is needed for the task at hand. Attention is focussed.
  • It allows you to change the controls, using the same space for different means. Gmail does this. This is handy when there is a lot going on.

The questions you should ask yourself are

  • "What does the user need to know at this point?"
  • "What does the user need to do at this point?"

Remember that no screen is in isolation. Each frame helps tell the story. So if you can establish an idea or pattern previously the requirements for this screen may change.

While simplicity is a great goal (potentially supporting not showing the button) you should never simplify more than necessary. Therefore if the user needs to know about the existence of the button, or you need to build the context, you might need to consider it.

A good testing regime should tell you this.

1
source | link

As with so many questions regarding UX the answer starts with 'It depends'. This is because UX is inevitably based in context and action.

Some arguments for using a disabled state:

  • Even if not in use, the user has a chance to learn that the action is possible. You may even have a tooltip explaining the criteria for use.
  • The user can learn where controls and buttons live within the interface. This assumes that if a lot are hidden at one time the structure would be less clear. (Depending on your design).

Some arguments for hiding the button:

  • Clarity. Only showing what is needed for the task at hand. Attention is focussed.
  • It allows you to change the controls, using the same space for different means. Gmail does this. This is handy when there is a lot going on.

The questions you should ask yourself are

  • "What does the user need to know at this point?"
  • "What does the need to do at this point?"

Remember that no screen is in isolation. Each frame helps tell the story. So if you can establish an idea or pattern previously the requirements for this screen may change.

While simplicity is a great goal (potentially supporting not showing the button) you should never simplify more than necessary. Therefore if the user needs to know about the existence of the button, or you need to build the context, you might need to consider it.

A good testing regime should tell you this.