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
Related
Similar to this iOS-question ( VoiceOver announces dimmed instead of disabled for buttons ) I have the same problem, but for Android devices with Talkback.
Why is Talkback announcing some elements like buttons or checkboxes as "dimmed" instead of "disabled"?
Should I somehow change this, or leave it as Talkback reads it? If I should change it to "disabled / dimmed" so that it's consistent over the whole app, how?
[EDIT]:
Example:
It seems that not only buttons use "dimmed", but check / tick boxes as well.
Also only the english language seems to use "dimmed", in german it's still read as "deaktiviert" (disabled).
Don't change it. TalkBack is responding to properties in ways that users would be accustomed to. Sometimes the default behavior is the most accessible because it is expected, even when it isn't quite ideal.
If you would like an answer to the "why" I would need more information on the particular examples that your talking about. Are there apps that exhibit this behavior? TalkBack updated not too long ago, but I generally hear the "disabled" announcement over the "dimmed" announcement from TalkBack from the "obvious" times that such an announcement would apply. I certainly wouldn't expect there to be a general distinction between the two.
Also, I'm looking through the current version of TalkBack (again TalkBack has been updated recently, so the open source version may not be up to date and available) and can't find the localized string "dimmed" anywhere. There are references to "screen dimmed" but this is certainly different from what you're talking about. Which suggests to me that the "dimmed" announcement is coming from changes in the code that I would recommend be UNDONE, so as to allow the "disabled" announcement that TalkBack users would be accustomed to. This sounds to me like something someone coming from an iOS background wanted to duplicate. The behavior in iOS is to announce disabled things as "dimmed". Duplicating this on Android would absolutely be innapropriate. Let TalkBack do its thing!
Providing code examples would be helpful for me to be more sure about all of these things, your question is quite ambiguous. What types of controls? A Button for example may behave different from a Tab in a TabWidget, and this may be intentional. The way your question is worded, any more specific answers than I have given would be speculative.
EDIT:
The different parts of this announcement:
Every Sunday (0): The text of the control
Tick Box: The calculated role of the control. In stock Android this will announce as "CheckBox" (I'm testing on 7.0, with the current GitHub TalkBack). Samsung would be best off to leave this as "Check Box" from stock Android OS, I don't know why they felt the need to change "Check Box" to "Tick Box" just to be different. Doing things just to be different is annoying, there is no objective difference between "Check Box" and "Tick Box" (licensing???).
Not Selected: The current calculated state of the control. In Stock Android this would read out as "Not Checked". Unless the app is overriding this, Samsung would seem to be mucking with this as well. They should stop doing so, but again, out of your control and best left alone. Samsung users will be used to this. Though ultimately I find "Not Selected" to be a little ambiguous in terms of a CheckBox control. "Not Ticked" I think would be better.
Dimmed: Again, another thing that, unless your code is overriding (which I don't think it can in this case for this bit of calculated state). This is the calculated enable/disabled state of the control. In stock Android this would read out as "disabled". Again, leave this alone. Samsung would ALSO be best to leave this alone.
It would definitely appear that Samsung is doing strange things to the Accessibility read outs of calculated components. I'm not sure what version of Android this Samsung flavor is built off of, but I don't believe those read outs have changed. I know CheckBox and Disabled have been the same since 4.2 - 7.0 (probably Android O as well.). These minor changes fracture the Android Accessibility Ecosystem. For these particular elements, Samsung would definitely be best off just to leave them alone. HOWEVER, given that Samsung has made these changes, you are best off NOT fixing this fragmentation. Let Samsung users and Nexus users and Motorola users experience things in the way they are used to and get accustomed to their devices. Allow default behaviors unless overriding them is absolutely necessary. Hearing "disabled" when your expecting "dimmed" is confusing, not to mention a maintenance nightmare should Samsung decide NOT to override this any more or vice versa. When the OS is "calculating" state and doing so reasonably... let it happen!
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.
Please give me feed back whether it's good practice to have a back button in activity, or is it just nonsense? Maybe some android phones don't have back/return key? Or do all models have them?
All android phones will have the back key. Putting a back button is, IMO, ugly and unnecessary; you better use your space with useful stuff. Sometimes your boss will just obligate you to put a Back button, usually because (sadly) most of the android sketchs are based on iPhone's ones... so the only reason why I'd put a back button is to not get fired (well, sometimes it's much better getting fired than becoming a poor programmer).
Piling on. I recently had a debate about this where we talked about design metaphors for android, iPhone, and windows mobile. The bottom line where we agreed is that you should follow the design metaphors for the device you are developing on. For android, the design should not include a back button because users are used to the physical back button. If one is required, the physical button should work as well.
I put a Back menu item in the option menu. The option menu in my apps seem to already contains other navigation-like menu items, so its seems reasonable to have a Back menu item in there. Having the explicitly labelled Back menu item there seems more newbie-friendly and the redundancy seems harmless there unless the option menu has a ton of menu items already.
OTOH, remembering that there is an option menu and remembering how to access it can be a challenge for some Android newbies. Yes Dad - I mean you. :-)
Similarly, on an Add/Edit screen, I provide Save and Cancel buttons, even though the Back button could be (and probably often will be) used to Cancel button. Again, having an explicitly labelled Cancel button seems more newbie-friendly and harmless. (What were you going to do with that empty space beside the Save button anyway?)
All android phones that want to have android market access need to have a menu, back and home button. those are the rules from El Goog. Some models may not have these but I bet that is a small number of devices.
I'm not sure if anything will change with honeycomb, seeing as Motorola Xoom has none of these buttons.
If you have an app that needs the space to exclude a "back" functionality, such as an "undo" functionality in a drawing app where you want to show the whole screen, then it's a great shortcut, but you better have a button as well.
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.
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