Is it a good practice to define the alphabetic shortcuts (alphabeticShortcut) of the menu items?
I ask because I've never used them in any of the Android devices that I have owned, even those that have a physical keyboard. Is there any reason to define them? Maybe an accessibility use-case than I'm not seeing?
Is it a good practice to define the
alphabetic shortcuts
(alphabeticShortcut) of the menu
items?
It doesn't hurt to have them, AFAIK. However, at present, I expect few users to use them:
They are not discoverable, at least on option menus, so users won't know they are there or how to invoke them
IMHO they are only really useful with a hardware keyboard, with the keyboard exposed, which limits their utility to a small percentage of Android device users
Now, I can see scenarios where Google TV might make greater use of them, but we won't know until Google TV hardware (and, particularly, input devices) start to ship. Also, you can define numeric shortcuts, which might be usable by more devices in the future, if we start seeing 12-key Android phones.
I'd lump menu shortcuts in with context menus -- nice to have, good for power users, but they should not be a critical piece of the user experience.
Related
This kind of behaviour appears on devices that have a hardware settings button (e.g. Samsung Galaxy S3). Apps like Hangouts or Slack use both an overflow menu and the menu that appears when pressing the hardware settings button.
Using an overflow button to show exactly the same options as the hardware settings button menu seems redundant to me. It also seems like it stands against best practices. Because such behaviour appears in many popular apps, I think this might confuse the regular user a little bit.
Is this to make the user's transition to newer versions of the Android platform easier?
Is it recommended to implement the options menu this way for such devices?
I suppose so it depends. Even an Samsung G5 or G6 have a hardware menu. Press the multi tasking window for a long time. It does the same as pressing an overflow button. This is so that the uses of older versions of Android can use there accustomed way of using the menu button. This simply provides your app with a richer User experience.
Especially value of minimum SDK version is very low it is recommended to use this to provide a richer User experience to your application. It is your wish as to how the app is supposed to workm
I want to prevent users from leaving the application (client requirement, not a mass public application).
But the IME allows the user to reach settings by pressing some touch. How can I block this without developing my own keyboard ?
As far as I understand from Google documentation, there is not much I can do because the IME is the first component to receive the screen inputs and it is the IME which decides what inputs my application receives.
Any pointer appreciated.
There's really no way to prevent somebody from being able to leave your app without a custom rom. However, Android 5.0 Lollipop allows device owners to pin the screen. For example, conferences that hand out tablets to their attendees are using the feature to restrict tablet usage to the conference app.
Here's a good write up to the feature:
http://www.androidpolice.com/2014/10/17/lollipop-feature-spotlight-screen-pinning-allows-you-to-lock-your-device-to-a-single-app-before-handing-it-to-a-friend/
Alternatively you could try one of the various launchers on the Play Store that use alternative locking strategies, but in my experience there's often a way around them unless they simply lock the device completely.
We’re porting to Android some interactive iOS apps used to teach young children with learning disabilities. We have hit a major usability issue, because we can't figure out how to disable physical or on-screen navigation buttons (Home and Recent Apps).
Before anyone says “you don’t want to do that”, we fully understand why you would always want these buttons enabled for an able-bodied adult, but these children pose a unique set of accessibility issues. Specifically:
Their fine motor control may be poor - they may inadvertently touch a different area of the screen to the area they intend, or accidentally use more than one finger at once.
They may have weak muscle tone and poor physical strength – so e.g. the bottom of the palm of their hand may drop and touch the screen while trying to just use a finger.
They struggle to achieve and easily become disheartened or disruptive if they fail.
For instance, a typical 5 year old child with Down syndrome will accidentally drop out of the app they are using as a result of inadvertently touching the Home button: when this happens repeatedly, and the adult teacher or parent has to go back into the app for them repeatedly, the child loses interest and focus. Another typical scenario is a young child with Autism, who may freak out completely and need physically restraining if this happens while using their favourite app. Also, many disabled children will try to poke any other button they can find, in search of a response. In any of these situations, a potentially valuable educational session may have to be completely abandoned.
We're aware of SYSTEM_UI_FLAG_HIDE_NAVIGATION and SYSTEM_UI_FLAG_LOW_PROFILE, but these only reduce the visibility of the on-screen buttons until the child touches some other part of the screen, and then they re-appear in a way that’s more distracting than if they were visible all the time.
On iOS there is the “Guided Access” feature that solves this problem trivially. Can we emulate anything similar on Android?
On iOS there is the “Guided Access” feature that solves this problem trivially.
Guided access appears to be a device setting, not something that developers enable unilaterally themselves, thank heavens.
Can we emulate anything similar on Android?
There is no similar device setting in stock Android.
You can download the Android source code, modify it as you see fit, build the results into a ROM mod, and install that ROM mod on devices as you see fit.
Or, you can perhaps work with a device manufacturer creating tablets aimed at children to see if either they have already added this capability to their devices, or would be willing to work with you to add such a capability in a future iteration of their devices.
Android SDK suggests developing button states (if on a custom background) around Normal, Disabled, Focussed, Focussed + Pressed and Focussed + Disabled etc.
What I have observed is that mainly android tablets and modern phones, they all have given up on a trackball and nobody really supports them. So in that case, focussed and the related states are something that will never become visible.
Is it necessary to include all those states? Or, can I intelligently save some APK file size by avoiding those graphics currently.
Please send your thoughts.. Thanks
I'm inputting my point of view myself. I have included all the states as of now because I think its best from a standards perspective and I think of one situation when users will really encounter the state where focussed styles have to be shown. I imagine the case when users have external hardware (like a bluetooth keyboard) attached and it somehow enables them to move to those buttons using the arrow key.
Please comment in your thoughts around this perspective too
Are there any requirements/guidelines for an Android device? like numbers of buttons or minimum buttons required.
Also are there any android devices which do not have the menu and back buttons?
( I am aware that no menu/back buttons will kill most of the apps in terms of usability , I just wanted to know more on the topic :-) )
Are there any requirements/guidelines
for an Android device? like numbers of
buttons or minimum buttons required.
Yes. These are documented in the Compatibility Definition Document.
Also are there any android devices
which do not have the menu and back
buttons?
That depends on how you define "buttons" and "android devices". Quoting from the CDD (see above link):
The Home, Menu and Back functions are
essential to the Android navigation
paradigm. Device implementations MUST
make these functions available to the
user at all times, regardless of
application state. These functions
SHOULD be implemented via dedicated
buttons. They MAY be implemented using
software, gestures, touch panel, etc.,
but if so they MUST be always
accessible and not obscure or
interfere with the available
application display area.
There are devices that do not have dedicated off-screen buttons (whether physical or touch-sensitive off-screen spots). The ARCHOS 5 Android tablet is one -- it has the HOME and BACK buttons in an expanded title bar. However, it is unclear if Google considered them to have met the CDD, since the ARCHOS does not have the Android Market. Devices lacking the Market may not meet the CDD.
So, it is entirely possible to create devices that do not meet the CDD, but at that point Android is mostly just another embedded OS, IMHO.
I would recommend this links:
Twitter for Android: A closer look at Android’s evolving UI patterns
Android UI design patterns
User Interface Guidelines