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
Related
This subject has been beat to death, but I'd like to give it one more shot. Every query I do from this site or basically google give several hint/tips on handling when the button is pressed, but from what I understand the Samsung Knox has the ability to disable the button, and I'm wondering if that's a custom implementation baked into knox or just something i'm completely missing.
My application will be set as the device owner application for other reasons, but I do not see any low level items regarding the recent apps button.
I am currently targeting Android 21 (5.0). We currently use commercial (non root, multiple manufacturer and OS level) phones that we provide with one of our apps being mapped to the home button and monitors accessibility, and the primary application we attempt to keep in the foreground.
A few things...
I'm not interested in making my application a kiosk application so that is not an option for mean at this time.
I can monitor for the Intent.ACTION_CLOSE_SYSTEM_DIALOGS and bring my application to the front (or handle differently), but this still allows for the button to be pressed and the screen to load for a bit.
I've attempted all of the options for getWindow().getDecorView() and setting the flags of SYSTEM_UI_FLAG_HIDE_NAVIGATION, SYSTEM_UI_FLAG_IMMERSIVE_STICKY, SYSTEM_UI_FLAG_IMMERSIVE (different combinations of the flags) during the OnResume, OnWindowFocusChanged, and as a callback listener on the 'setOnSystemUiVisibilityChangeListener'. This works OK for a while but after several pull down attempts on my Pixel 2 the navigation is stuck open.
I'm not very well versed in the capabilities of an application that is the device owner, but I cannot find this lower level configuration option available.
Any help is appreciated
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
My Samsung Galaxy S2 running Android Ice Cream Sandwich has nice little counters that appear on the home page shortcuts for Mail etc. telling me how many new messages there are waiting. That's just the behaviour that I want for my own app.
If I've read the Android docs and related questions in SO right, that behaviour is not exposed through Android, but is provided by the launcher itself, so it can't be done directly.
But I have produced the behaviour that I want using an app widget. Now I'm left with the problem of making the app widget layout visually consistent (alignment, text appearance) with the appearance of the regular shortcuts. I can't see a sensible robust way to to this. Anyone?
(Otherwise it looks as though I'll have to make the app widget look sufficiently unlike a shortcut that visual consistency isn't an issue.)
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.
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.