First, regarding answer that you linked, I think what Apple was having an issue with is the use of the same UI as their slide to power off, not the use of that UX/interaction. They just don't want it to be styled to resemble their power off slider as to not confuse users. If you were to create say, a small blue slider, or a slider that moves in a circle ...
To send money in my banking app, I must drag a symbol into a target. It is difficult to do accidentally, but quick to accomplish. It may be difficult for someone with limited dexterity or someone who is distracted.
I haven't thought this through, but there might be mileage in considering the physical equivalent. On many control panels, such as in power plants or aircraft, the especially dangerous actions have a switch cover that must be lifted before the button can be used.
My suggestion is a control that's normally in a "locked" state, and takes an action to unlock ...
Additional ideas from this article:
Delaying the action and allow a window time for users to "undo"
Extra step for security, such as asking for fingerprint
Other types of authentication such as re asking password or 2-factor authentication.
Other articles dealing with the same topic:
Let's Talk User Flows & Navigation:
User Flows are a series of steps a user takes to achieve a meaningful goal 1.
From The Science of Great UI by Mark Miller - When User's Navigate through a task, the path they take to accomplish it can be broken up into into individual steps for each context shift.
Path - Set of Steps needed to complete a task
Depending on the environment that you are developing in you could use either; however, searching stepper in regards to UX design returns more results leaning towards Google's definitions.
UX Planet uses stepper in the context of a stepped process, for example account registration or order delivery.
Guiding users through a complex process by making it ...
I have seen some apps use a brief animation that slides over, partly revealing the hidden feature, and then slides back to notify the user of the hidden features. This could be done upon first load or when a user taps on one of the list items. Previews like this avoid the interruption of a pop-up while telling the user that there are hidden features. As well,...
You should give the user control over refreshing the data, give them a notification that new data is available (or that data has changed) and tell them that they can refresh the view by pulling.
You already mentioned the big con of updating it without user interaction.
But, as always, it depends on the use-case. If you have data that changes every 2-3 ...
Yes, it is the same with iOS and the tab bar should be visible everywhere.
Don't hide a tab bar when people navigate to different areas in your app. A tab bar enables global navigation for your app, so it should remain visible everywhere.
Many apps opt to keep the swiping as a discoverability feature, because they rely on their target audience figuring things out on their own. But, not every group will do that, and generally the older they get, the less likely they will trial and error their way through an application.
As you mentioned there are multiple ways to figure out what your users ...
They are common in iOS apps because they are part of the iOS system interface.
The official documentation is a good starting point: https://developer.apple.com/design/human-interface-guidelines/ios/views/action-sheets/
There are also examples in Material design: https://material.io/design/components/sheets-bottom.html
So I believe to your question "how ...
A user's spatial memory is sensitive, and moving items can also be the same as removing them.
Spatial memory is what we use to navigate the world, and it means that once we find something in an interface, we tend to remember where it was rather than how we found it. Accessing the spatial memory of its location is faster than repeating the cognitive process ...
Considering left-to-right mentality, I think, the difference is this:
If it’s to the left, the user will read it as “we’re working, and here’s why...” - they’ll “read” the indicator first and then, if confused or interested, the description for it that will clarify what’s happening.
If it’s to the right, the user will read it as “we’re doing this and this,...
For guidance, I'll reference an answer on this site to similar questions:
From a UX perspective [the press-and-hold (or long press) gesture] is kind of odd, since there are no clues that the long press exist on an object, and the user is left to trying it out if they haven’t read the manual.
-- Benny Skogberg
The long-press is a functionality users ...
Since you want to show the 2 charts, I am assuming the user's motivation is to compare multiple datasets over a period of time.
As sessions and time duration are closely connected I feel putting them together on a single chart will provide more inferential insights.
Contextual data at the same place
Easy to identify a trend
As mentioned by @katriel, the Web Content Accessibility Guidelines (WCAG) are the official W3C specs on how to create accessible applications (whether web or mobile).
Version 2.0 came out in 2008 and Version 2.1 came out in June 2018.
Most country laws are based on Version 2.0 (at least for now) but that will be changing. The European Union is typically ...
Take Googles Material Icons page for instance - is there anything
similar at all for iOS?
Yes there is. Apple makes a difference between app icons and system icons, which are more similar to those listed at Material Design, just take a look to System Icons (iOS 12 and Earlier) .
From iOS13, the icons change to SF Symbols, with 1500+ icons in different ...
iOS recommends using PDF as the vector format for custom icons, see this link
Prepare glyphs with a scale factor of @2x and save them as PDFs.
Because PDF is a vector format that allows for high-resolution
scaling, it's typically sufficient to provide a single @2x version in
your app and allow it to scale for other resolutions.
I think it is based on the user expectations and as a user, I don't expect to see the "Home" button in the top-left of the screen in a mobile application
Expectations with the home button in an app
When I see just a Home icon, I would be hesitant to click it because I can't be sure of how to get back to the previous screen. Also, I might not be aware of ...
Apps must get permission to access private data (even if they are technically capable of getting it without asking).
You and those who work on your app may be trustworthy and only use the contact data for displaying a list, but this is not always the case.
When using Apple's CNContactPickerViewController from ContactsUI "The app using contact picker view ...
Yes, it is necessary to ask permission when accessing native tools like contacts, camera, etc. It has been designed this way to protect the user from an application asking for or gaining access without their expressed consent.
Imagine if an app labeled that action with something that had nothing to do with accessing contacts and the user clicked on it. ...
Devices often share similar screen dimensions, so it would take forever to create a version for every possible device configuration.
The most efficient way would be to create a single, scalable layout (see Material Design, for example) for each device type, e.g. phone, tablet, and desktop. However, you could consider creating versions for each operating ...
Different design teams.
The app store bar is not in the nav bar has a longer title, so I assume it did not fit.
The iTunes one, probably a stronger focus on the content to have those pixels available for selling.
Each app developer has their own method for building and there are numerous ways to do it, as such, there is no set method. As UI/UX designers, our goal for the app developer is that they build out the app as we had imagined it. Therefore, you should ask the developer that you are working with what they need from you to develop the app. The goal is to make ...
Changing the layout of your content area while the user is reading something would drastically downgrade the user experience. I would say that a manual reload is mandatory, either by pulling to refresh or clicking on a button, depending on how you are implementing your application.
For example in my experience, a pull to refresh is tedious in applications ...
Like exp mentioned in the other answer, both the approaches have different narratives that makes sense. Adding to that:
Visual designer can direct the flow of reading in a correct way. Though having an icon to the right may appear optically balanced, the reading flow will be broken because of the bold stroke, dark colored icon. Adding to it the animation ...
Considering both landscape and portrait orientations (perhaps even more: square...or special form factors) is "doing it right". Most designers, developers, and teams don't do it right. I try to get everyone to do it right, that is raising the bar. The result is a more usable app, that works better than competitors, and even runs less risk in terms of being ...