If the items have different behaviors, then they shouldn't have a similar icon. What I suggest is a button.

Depending on if a user can go a to a previous step, having a "BACK" and "GO" button to navigate through each view doesn't give much insight, but it would be helpful to describe each "view" with a specific name. That way, you could name each "BACK" button the previous view, and each "GO" to the next view. If you give each view a name and display what category they are currently viewing, users will always know where they were previously, where they are currently, and what the next step will be. Then after they are all done, make the button describe what they will see when they submitted. (i.e. "VIEW REPORT", "SEND DATA") (Also, progress bars are extremely helpful to users to know how far they are along the sequence.)

I am not sure for a specific and "correct" naming of this element but I would call it probably a card since I would be desperate to find a better naming for it. You could see if that fits your need.

Can't speak about completely blocking the iOS wallet app (maybe a question for Stackoverflow?). Regarding making it clear that you are not asking for payments, you can add a page explaining that, which shows up before the pop-up. Another way could be to have an FAQ section on your app that explains this popup.

This is a rather broad topic but in general you should start by thinking about the same types of issues that you would encounter in basic web accessibility that you would for mobile, as indicated in the https://www.w3.org/WAI/standards-guidelines/mobile/ : Mobile accessibility is covered in existing W3C WAI accessibility standards/guidelines. There are not separate guidelines for mobile accessibility. But there are some additional content regarding https://www.w3.org/TR/mobile-bp/ with a long list of things to consider including: Navigation and Links Page Layout and Content Page Definition User Input

I think the most intuitive in this case, knowing it's a modal window, are some radio buttons and a text field for the last option, the simpler the better:

I like the horizontal one more since it's give at least some context for other available options. I would consider the option to select multiple filters at once tho. Especially if there is not many possible filters it can be beneficial to swap between different combinations. https://material.io/components/chips#filter-chips

I just ran into the same dilema 2 weeks ago while designing a rating feature. The main issue with approach A is that if users make a mistake, can they go back to the previous answer? If the not, then it's a big margin for error. Allowing users to review their answers before moving forward is always a good idea. Also, it's not intuitive that by tapping an option that the screen will change to the next answer. A 'Continue' CTA, on the other hand, matches users' expectations and in general it's a good UX. I would recommend approach B.

You can show number of results. Customer will be understand when the number is changed.

The most illustrative, direct, recognizable, and easy-to-understand element for any user for an event to occur on a given date/hour/minute is a countdown. Image source https://dribbble.com/shots/13844344-Daily-UI-014-Countdown-Timer

There is a good article on Medium written about the https://medium.com/tap-to-dismiss/a-better-segmented-control-9e662de2ef57 including this nicely presented flow chart / decision tree that you might want to reference and understand so you can apply it to your own project. The other point I'll make (which was touched on in the article) is about how creating a new component or pattern can have an influence on the rest of your user interface design or design system, so you should also think about the bigger picture. So to answer your question, I think whether you should combine the dropdown with the segmented control depends on whether you think that they should be separate actions and also if this is something that is a one-off use case or a design that you want to take forward and apply elsewhere.

There is no reason. It's based on their own unpublished independent research. You should always follow w3 guidelines for accessibility. https://www.w3.org/WAI/WCAG21/Understanding/target-size.html It clearly states to have 44x44 CSS pixels.

The borders around buttons and call-to-actions provide a much clearer representation of the physical contact/touch point for the user, although generally the user interfaces on mobile is laid out in a much tighter space so it may not matter as much as when you are designer on a desktop for click interactions. The combobox is a term used for specific types of dropdown input control that can be combined with other features, such as a search or multiple selection rather than just a simple dropdown list from which you can select one item only. However, depending on the operating system or design framework you use it also might mean different things. I think you can keep the function of the dropdowns (or combobox) similar to the app you are trying to mimic, but in terms of the style you should probably consider whether you are also trying to mimic the app or doing something different, in which case the border around the controls might not suit your particular purpose.

If the user has already seen the image and wants to see its locations, the detail of the image is no longer so important, just knowing that the map refers to that image. You can change the display mode to image's thumbnails at the bottom, with the option to select and move forward or backward, and the map in the center of the image.

If the user is leaving the app, typically when they return to the app, they will land on the screen they were last on. However, if the user has left the app and has tapped on an app push notification from their home/lock screen, the expectation is they will be brought back to the app to the page/activity related to the notification if not the same page they left.

It is not the standard and I don't think it should be The standard seems to be Page with small thumbnail of video User clicks thumbnail -> Video starts playing in small frame User clicks expand button in video -> Video expands to fullscreen I have not seen it any other way. And I think it would be distracting to play the video in fullscreen in the second step. Here are some reasons: User might just want to start the video to hear the audio (and browse the rest of the content, e.g. comments) User has not decided if the video is any good. In the beginning the user wants to know if the video is good in terms of content and quality. If the audio is bad or the video is full of ads, a user would most likely end the video (not requiring fullscreen). Fullscreen playing the video requires the user to rotate the phone to landscape view. Users don't like to be forced to rotate their phone.

You are right, the general rule is: stay consistent. On the other had, rules are there to be broken if there is a very good reason. This sounds like a good reason to replace the back button with a "Start Over". To be sure, please test this! If users are really confused by this replacement, add a button to start over.

You are right, that a back arrow in the top left corner would probably cause confusion here. The X could work, though I'd test this. As the consequences fo pressing the X are pretty harsh (losing all the data), I'd recommend a confirmation dialog. Please avoid the word "abort" in this context. It has been common practice to use "Cancel" instead for quite some time now.

It's also not clear to me. There are two mixed concepts: setting and editing. If you don't clarify these two options, either together or separately, the concept of editing will never be clear. There is the edit/settings icon but I don't think it's entirely clear. On the other hand, in your app I think the option to edit is not mandatory, the user can only access it to view. Icon from https://stock.adobe.com/ee/search?k=edit%20icon&asset_id=234382730 I know that it may not be the intention, but the most accessible and understandable option for any type of user, even though the modal window is editable by default, is still to include the edit, save and discard changes buttons.

It's all right as long as there's a decent reason to have multiple flows leading to the same view. You can find an example on this page, e.g. the website tour page can be opened from the footer and one of the top right menus. Such duplicates should be introduced with great caution since if there are too many it most likely indicates that there's an issue related to the website structure that makes too many duplicates necessary.