With regards to your question of whether a bot can actually go and submit a form automatically, this is what I found on an answer on Stack Overflow.
It is comparatively harder to automate data submission within native
apps. This is due to the fact that you cannot just write an automated
script to discover elements within the source code and then
This study of 1,333 people has some great information on how users hold their phones, and which areas of the screen are most accessible.
Their data showed that people held their phones in 3 basic ways
one handed — 49%
cradled — 36%
two handed — 15%
The accessibility heatmaps looked like the following:
Cradling in Two Hands
I would keep the message short and simple,
"Unfortunately, iPhone devices do not support W3C standard HTML video"
This still allows you to shift the blame "devices don't support our application" as opposed to "we don't support your device".
Why not longer?
If you go in to details about how Apple refuses to follow standards and ...
If truly nothing can be done to make something work for iPhone users. Then be honest as possible in your notice saying the app is not supported, and succinctly provide the reason why, and how the user can get around it.
Here's a quote from an article on medium about error messages that applies equally well for your use case.
Write an alert message that ...
Snapchat recently added image recognition:
As most captchas, this is also breakable.
But until your app becomes a popular target, this is a pretty nice alternative ;-)
People with Parkinson Disease (or PD as it's also known) need special considerations as you correctly figured. However, keep in mind that most of those considerations are covered by special peripherals rather than specific UI. As a matter of fact, just following common WAI- ARIA guidelines is more than enough.
Keep in mind that, like many people with ...
The iPhone 5/5s/se size. There are three key reasons:
More people today still own the smaller 4-inch model than the larger models. That's also not likely to change thanks to the lifespan of the iPhone and the recent release of the iPhone se. So unless you are targeting only people with larger phones, best to stick with smaller and scale up, not the opposite....
Rather than asking the user to answer a question or choose a correct picture or enter something, another option is to simply delete something from a regular text field.
From an implementation perspective at least, it could not be easier!
Please DO NOT use most of the examples in the upvoted answer, they completely exclude people with a wide range of impairments (image recognition is useless if you're blind, metaphorical association is useless if you're autistic, maths questions are useless if you're discalculaic etc etc), and they also do nothing at all to remove the problem of humans ...
My father has late-stage PD and after watching him use his Mac for the last 15 years here are some thoughts in no particular order:
Assume the user can't use both hands or combinations of keys. My father uses his non-dominant hand with a track-ball because it shakes less, but has to use the keyboard and click with the same hand. Try that one out yourself ...
You shouldn't rely on just color for this. Most colorblind people cannot differentiate red and green, especially on very small icons. One possibility is to have some sort of network connectivity symbol to show when the connection exists and put a large red "X" over it when the connection is off. Use color to reinforce the symbol shape. Even spell out "...
If it makes sense in your case, you could use informal wording, like Trello does.
Also, while average user won't know what W3C or standards are, they usually have heard of HTML5 and/or it's video.
Sadly, we're not allowed to make nice things with HTML5 video on iPhone
It works fine on iPad or many other devices, though!
Is bot traffic from an iPhone (or Android device) actually a problem?
The problem is not so much 'from an iPhone', but rather that the API you are talking too needs to be protected. At the underlying IP level there is not much you can do to prove what a remote device is, for HTTP it is really just the headers or form data, which a Bot can generate easily. ...
This sounds like it could also apply to a horizontal main navigation for a site. Brad Frost has several options for responsive navigation systems, but the next two seem most appropriate to what you're trying to accomplish from his options. Here are those two and a third approach:
A popular way to solve this is to switch from tabs to a ...
Google doesn't always make the best or consistent UX decisions. Their Google Voice application (which I assume is created by an entirely different team) has "New" and "Refresh" buttons at bottom-left corner.
But I agree with you, putting the "+" in the top right corner is poor usability for frequent-user of the app. However, it does make the button stand-...
I see the tab used as a primary navigation and placed at the bottom of the screen, whereas the segmented controller is more like a local switch inside a particular screen and is usually placed at the top.
They are quite similar in terms of functionality, they just differ visually in the sense that the bottom tab is heavier and conveys more important actions ...
I don't agree with this reasoning:
In my view the hamburger menu is a placeholder for these tertiary functions. It shouldn't exist. Apple didn't create it. Apple doesn't use it. Why should we?
Just because Apple didn't create or uses it doesn't mean that it doesn't have value. While in general I would agree that the best apps do a great job focusing on ...
I can't believe what I'm reading in all these answers. Not a single person has referenced Apple's HIG.
Resist the temptation to display your logo throughout the app. Mobile device screens are relatively small, and every occurrence of a
logo takes space away from the content that users want to see. What’s
more, displaying a logo in an app doesn’t serve ...
What I've learned from observing some mobile usability tests: Don't care too much about "thumb hotspots".
Which areas of a smartphone display are more accessible differentiates a lot from user's individual abilities and habits. As there are:
Individual phone holding: Some users are holding their phones more at the bottom, others at the phone's mid. The "...
In general, it's much easier to scale a design up from a smaller screen size to a larger screen size.
So I always start with whichever is going to be the smallest device. When you're scaling up, you can always add whitespace and have a balanced design, but you have no such option when scaling down.
Apple's iOS guidelines say to "Think twice before hiding the status bar if your app is not a game or full-screen media-viewing app." I think their attitude is that if you don't really need the extra space, leave the status bar visible so people can see the time and battery life. Also, from same link above, "don't create a custom status bar."
Let's take a step back and look at your business model. Should you even include ads in your app in the first place? Are they likely to be successful?
For advertising, context is everything. In general, ads are most effective when the user has what is called "commercial intent", meaning they are looking to make a purchase. The next most effective ad is when ...
Apple tend to try and mimic real life behavior as much as possible in their UI.
For example, while casing is reflected on the keyboards of all OSs, in iOS, the keyboard always shows the letters as capital letters, even if the shift button is not pressed. The logic is that on the physical keyboard, the cases of the letter printed on the button do not change....
You could use honey pot fields.
They provide a field within the form that is hidden from the user but designed to be noticed and filled in by any given bot.
They can be as simple as a field called 'phone_number' hidden with css. The bot doesn't process the css and sees the field, but the user doesn't.
This would work on both desktop and mobile and has ...
Since you mentioned HTML5, I'm a big fan of the honeypot approach. Most of your users won't even know it's there. Use all four of the following input fields which you must validate server-side on submit:
Required, hidden by CSS
Must be null, hidden by CSS
The required fields should ...
Each option has own drawback.
Hamburger menus are, in essence, hidden menus. That means you have to
click somewhere to see the menu.
Bottom menus are limited in size, so that's why you cannot add many buttons there.
So, I completely agree with ekapros: If you have few buttons which will be used frequently (functional buttons) by user, then go for bottom ...
There's no need to over-engineer a loyalty system - there is a really cheap and simple app for loyalty bonuses at every n-th purchase:
Card and ink!
A simple web search for 'Loyalty Stamps' will give you a wide choice of stamps to choose from. The main benefit of keeping is simple is that you avoid ALL of the downsides of trying to use technology (...
I'm assuming they're talking about something like this:
From what you've described, they might be looking for something like classic iOS date spinner, or the Material UI "datetime-local" component found here: https://material-ui.com/components/pickers/
Each number field - day, month, year, hour, minute - can be moved up or down via the keyboard, similar to ...
If you have a separator line between the "Landing page" text and the chevron (arrow), it implies that selecting each performs a different task, which is fine.
An app that I did usability testing on used this separation, and it was clear to those that I tested that they performed different actions. Interestingly, when I used the iOS detail disclosure ...
The first question you need to ask is, how important is the visibility of the menu items?
If the user needs the menu to be always visible for quick access, then, a bottom menu makes sense. Show the 4 most used items and then hide the remaining under 'more' or something as the 5th item.
If your items have status indicators - like number of unread posts, or ...