New answers tagged

2

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 ...


3

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: ...


15

Do not disable buttons. Disabled buttons predate modern touch screen usage and don't work in this environment. Solution 1 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 ...


63

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 ...


0

From a UX point of view, the best practices would be consistent with user behaviour and expectations. This being said, however, I am providing some ideas to help you consider what would be the user expectations for your application. For Ok/cancel button alignment, the OK button is usually done on the left in Windows or on the right on MacOS. So it depends on ...


1

This recently came up at my company too. Some HIPPO decided that primary buttons should be set flush right. Yet everywhere else on our site, primary buttons are flush left, with the secondary button adjacent to the right. At least that's the pattern for right-to-left languages. For Arabic and Hebrew, it's flipped. All the sources I found agree that there ...


1

I think the biggest problem with your draft is not the quantity of buttons, actually this is easily solvable on practically any screen size. In my understanding the most serious problem is in the design itself or if this is just a scheme, in how it's solved. According to the description, there are five buttons, but the diagram shows five different entities ...


0

I would suggest grouping everything related to score under a menu with an icon like this:


1

You absolutely should not use “add appointment” in this case. Your system obviously has a facility to create new appointments, as that’s how the user got here. So you cannot be surprised if the user interprets “add” to mean “create a new record (and cancel the one you are currently creating)”. You might think it is clear from the user interface language you’...


1

Grammatically speaking, "appointment" requires a determiner. We've gotten so used to menu items sounding like Zork commands that it seems normal, but we have determiners for a reason: they decrease ambiguity. If you say "add an appointment", that clearly means to create a new appointment. If you say "add this appointment", it ...


0

You haven't given enough context of if customers will be using this or would it be internal staff. The text would also depend on the UI it is on. I'd recommend you use "Book Appointment" or "Create Appointment" Also If you were later considering making changes to your appointment, then you might have to consider using 'save' to save ...


0

If the action is to 'Book Appointment', I would stick to having the exact text that describes the action as the button label. This article might help you. However, to answer your question above, I personally believe 'Save Appointment' is better than 'Add Appointment'. Unless the 'Add Appointment' would indicate adding the appointment into a calendar/to-do/...


0

Your question should be Does it help my users to show a progress indicator inside my buttons?"I'll explain why. There is no right answer to this but you highlight some context in your question This is for a desktop app, if it matters and The advantage is that the user always knows which command of a few is executing. Why are those two statements ...


6

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 ...


Top 50 recent answers are included