Tag Info

Hot answers tagged

51

There is no good way Here's the design logic: Backgrounds are perceived by users as backgrounds, i.e. inert and uninteractable. This is obvious. In order to communicate to users that the background is tappable, you need to tell them that. The most reliable way of doing this is to sign it, i.e. Tap to continue. Note that trying to do something fancy ...


29

What is the better solution? The always-active button. Why? With an always-active button, you can select it, and then be told what isn't complete. With an inactive button, you are stuck. You may not know why it's inactive and as such, hit a dead end.


23

What's the issue with giving the user a predefined region of space with some sort of indicator that that space is where they should tap to continue - a button with an appropriate continue icon (the right-ward arrow is popular), for instance? From a UX perspective, you're removing a level of complexity by removing an unnecessary choice, namely where on the ...


6

No; it's uncommon and would lead users to thought that action has been already performed after mouseover, rather than indicate possibility of clicking. Also, note that volume control in vast majority of cases is under control of user and it's often the case it's just set to 0. I would suggest: Underlining, changing background, changing/emphasizing ...


5

"On that screen, the user can tap anywhere to return to the gameplay screen." Without knowing what "gameplay screen" here are two suggestions. A common iOS strategy of presenting several view screens (gameplay and the one shown here?) is pushing and popping views via the navigation controller. That is if said view is a child of the 'gameplay view'. The ...


4

In the game "Two Dots", messages are shown in small dialog windows that have no buttons. To dismiss these, you have to tap on the background. Perhaps this solution could work for you.


4

I think this can be handled by looking at how you've prepared the user experience thus far. If the game has had several screens with small load-times up to this point, then the user will expect to have to do some waiting at these screens while the game loads/gets enough time to deliver a message, to continue. If you consistently have 'forced' the user to ...


3

If the elements are required for proper navigation then don't think about clutterness, You can provide any button to 'go back' or to 'continue' in minimalist design. I also suggest to provide the 'Re-play' option on 'Lost' screen to play again.


3

In Material Design on Android it's common to make displays as virtual "cards" that overlay, say, the left 80% of the screen. The user swipes right to left to dismiss the card and return to the previous screen, which is partially visible behind the card. By visually layering the content, the user has a clear cue they can get back to the content below by ...


2

On the other hand, Blizzard, one of the companies best known for their intuitive UI, has done this for their iOS Hearthstone app: Simply saying "Tap anywhere to continue" isn't out of the question if you don't do it every other second.


2

I got addicted to the addictinggames.com website for my flash game fix back in it's infancy and the complete list of games didn't have a scroll bar and watched them grow. I got the impression that in the game in question your going to be seeing the game over screen every 5 seconds until you learn the basic skills needed to survive. In that case my solution ...


2

From a UX perspective, there are things that could be done to help the user experience by not setting pointer-events to none. Showing disabled fields to a person is sometimes cruel. If the rules for why the field is disabled are complex and not obvious from the screen layout, it is like holding a carrot just out of reach of the person trying to use the ...


2

On the apps I work on (which are similar in nature) the Save Button is always there but it's grayed out if required items are not filled out. The Save Button becomes active when the required information has been entered. EDIT: See DAO1's comment: "Inactive buttons are incredibly annoying. There's no indication as to why they are inactive providing no way ...


2

Yes The reason is, explicit design is often better than implicit design. A submit button does more than just submit the form. It communicates to the user how the form works, and how even a micro-workflow like a single input box is supposed to work. Assuming that a user (particularly for a consumer app) knows that Enter means submit is presumptuous ...


2

I have tried to visualize after going through the problem statement. In your use case, there are important things missing. Those are the feedback from system. For example, after entering the URL, username and password, there must be confirmation to user, that he/she has been logged in. And ready to fetch the data from the server. I do not agree with ...


2

Use semantics to guide visual design Each button has a different function/meaning, but the functions are differently related to each other. The Post it and Save draft buttons are semantically related because saving a draft is an interim step to posting it. On the other hand, Cancel is the semantic opposite of Post it, because it abandons the form ...


1

I think with any naming conventions, consistency, familiarity and logic are your best friends. The problem with the word "Generate" is not much the term, but the lack of context around it. "Generate New Report" makes more sense than "Generate" or "New". But keep in mind that once users know what "Generate" means, they probably don't need to be reminded that ...


1

The position of the button depends on the use case and whether or not your toolbar is a global bar or specific to the current view of the app. The left side of the toolbar is typically reserved for actions associated with the current view of the app. In the use case you provided the toolbar is custom to this view of the app (only appears during profile ...


1

Don't hide it: Because users might think there's no button at all (therefore action) and get really confused + stuck. Don't disabled it: If you want to tell users that they did something wrong, wait until they do it! Even if you apply inline validation, the user could avoid the fields and disabling the button will give them no clue about the need of filling ...


1

One way to accomplish this would be to place a label, for instance the word 'tap' or 'continue' at the bottom. Users would see that and select it to continue. However, if in addition to that, you make the whole screen respond to a tap then, as users become more comfortable with the application they will know that they can, in fact, click anywhere.


1

I would suggest using something similar to Google Analytics - Goal Creation page. download bmml source – Wireframes created with Balsamiq Mockups This way the user doesn't have to click on the "get list" button, making it easier to use and process.


1

I would not use pointer-events:none; on a disabled button. It's better to manually set the cursor and hover effect to the default/disabled state. In some cases it's useful to add a tooltip to a disabled button; pointer-events none would disable this. I've added a use case for pointer-events:none; below if your interested.. Pointer Event Use Example ...


1

If there is no logo at the beginning, you propose the user to Drag&Drop or to upload the image by "Choose file". If there already is a logo, you don't do this, so a user can forget it is possible to do something with the picture. He/she might feel confused thinking it is not allowed to change, if he made a mistake. The offer to delete or change should ...



Only top voted, non community-wiki answers of a minimum length are eligible