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 how you guys have tried ...
Some phone numbers are tailored to use a mnemonic "lettered" version to be more easily remembered.
Think of an insurance company running a commercial on TV and its goal is that you call their number.
If they use 1-800-INSUR-ME, it'll probably be more easily remembered than 1-800-4678763.
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....
Because whitespace is important. Being able to quickly skim the list and pick out who said each response is important. By adding left and right whitespace it makes the list of messages far easier to scan. It also makes the application instantly accessible from the very first sight; if it were just white and green with no justification, then people seeing the ...
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!
If the gesture is easier than the code, why haven't website login pages adopted this?
Accessibility: How is someone supposed to draw a squiggle if they can't use the mouse?
Recordability: Look at a numeric keypad (1 in the lower left corner). "183456" is easy to write down in a text editor for the memory-challenged. Furthermore, the only squiggle I could ...
Here is what I would do to have A/B Testing done on Existing Customers / People who already have my app:
Both the flows of the App you have in mind should be bundled as a part of the same app.
You use the code injection to send information to Flurry.
Use the same method to check how many users have downloaded the latest version of your App with both ...
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-...
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. ...
The general thought here I believe is that the received messages are given visual priority for left-to-right readers.
When you think about the fact that you have to type out your message and hit Send before you actually see it show up in the conversation list, it makes a bit more sense. You don't really read your own replies (in the conversation view) as ...
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 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 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 ...
They do this because it is easily recognizable by their users. Apple stresses using standard interface elements in their iOS Human Interface Guidelines:
In iOS, the UIKit framework provides a wide range of UI elements that you can use in your application. As you design the user interface of your app, always remember that users expect the standard views ...
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.
The presence of a submit button is a large part of what makes a form apparently a form; excluding it on Mobile may confuse users who prefer to touch buttons or are unaware of the Enter key to submit.
The submit button is also a lovely visual indicator of the end of a form; if I saw a form without a submit button on a web page I might assume the page didn't ...
You might follow the Gmail web app for iPhone example. It combines pull-to-refresh, a top control bar, and search (hidden by a button):
This arrangement allows search to compactly reside in the toolbar until it's required, completely skirting the confusion that might arise around a mechanism where you pull once for search and pull again for refresh.
Working on the assumption that you've addressed the information architecture issues and determined that there are infact this many primary and secondary navigation options required for the application there are a few routes you can take for displaying multiple options in a tab-panel (or similar control).
The first example here is from Snapseed:
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."