I have an action bar with a button to flip between two different views (list and tree). Should the button show (a) the current view or (b) the view that will be shown if the user clicks the button?
This is an age-old UI problem with no "right answer", only UI standards, so I'm trying to understand if there's any standard on this in Android.
I agree on the 'age-old' part. Myself I'm still questioning - when acting as a user, not a developer ;-) - what the button in front of me will do when I click it: turn on Shuffle or turn it of.
Now very pleased to come up with a feasible answer.
Since the user has a clear visual clue on the state the current presentation is in (List or Tree) the button would show the alternate option. Then the user knows that there is an alternate option and hopefully the button displays where it will take the user.
For more unclear situations I would still go with this approach. The user either knows or perhaps can deduce the current 'state' of the app ("hey it plays a whole different song now, so it is in shuffle"). So the button will bring me to another state, the one displayed.
Why display what the app is already doing and not displaying where a buttonpress will take the user?
Related
So I have a requirement around accessibility wherein a button needs to be read out when it comes in focus and then another text to be read out after user clicks on it.
For example,
An "OK" button when focussed should read "OK" but when a user taps on it, it should read out some other text eg. "Navigating to the other page".
Is there a way in Android to implement this?
I have not been able to find anything around it.
You can use View#announceForAccessibility(CharSequence) to make a general announcement - so in your OnClickListener get a reference to some View (e.g. your Button, it doesn't matter what it is) and call that on it.
Like it says in the docs, this is a convenience function that creates a very general "something is getting announced for no specific reason" event - you might want to give more context, like creating a TYPE_VIEW_CLICKED event. This might be more helpful to the user (depending on how the accessibility service handles it) and could provide a better experience, since stuff that's read out is prioritised depending on what it is. I don't have time to get into it here, but it's something you can investigate if you want
Also I'm not sure if this is what you mean, but just in case - if the user focuses your button, it should say "[OK] button, double tap to [some description]". The bits in brackets you can customise, the rest is standard description for a Button in the UI. You shouldn't change this to just say "OK".
That predictable and consistent system is there for a reason, to help partially sighted and blind people understand exactly what's going on with the app they're using. It might sound clunky at times, but it's meant to be functional, not slick. So we shouldn't try to get around it and make it "sound better" by removing important info and context that some people really need. I don't know if that's what you meant, but it's always worth mentioning!
I am working on some online shopping application. In this, we have Update Remove quantity buttons to manipulate cart quantity.
This works fine in normal flow. but when accessibility is enabled, It got quite complicated as user needs to go back and forth on plus and minus buttons to adjust the quantity after that user needs to remember to hit Update and Remove buttons.
I was thinking of a solution if we can override "SWPE_UP" and "SWIPE_DOWN" gestures after some view clicked so that the accessibility user can easily manipulate quantity by swiping up or down and once the quantity is set, respective buttons can be clicked programmatically on double tap.
I have gone through some articles and searched behavior in similar apps, but couldn't find enough reference material. They won't have similar problems as most apps don't have Update or Remove buttons.
If anyone can help me to find a solution or provide some reference material then it would be a great help!!
I have a list section in an Android app that includes a search functionality with filters (e.g. country, city, etc...), each filter takes you to a different activity that has a list of countries/cities/etc..., there are 2 buttons (Search and Clear All) other than the back button in the header and hardware back key.
My question is about the behavior of the buttons, when the user searches for a criteria and hits Search, the result in the list will be refreshed. When he goes back for a second search, the criteria he already picked will be selected. If he clicks Clear All but doesn't choose any new criteria and hits the back button, should the list be refreshed with the empty criteria like a reset or should that only happen when the user explicitly clicks on Search to confirm it?
I personally consider the back button as a cancel action, but others seem to think the opposite.
In your case, if the user doesn't select anything and presses back, then According to me it should not refresh with empty criteria. As far as I have seen in the mobile apps, the selections refresh the content as soon as they are selected.
For eg: If you have checkboxes, and the user checks any of them, it refreshes the content.. The user unchecks it, it refreshes the content again.
So there can be two ways to go about it.
Either do it dynamically as soon as the user selects a value, which I think is not the way you would prefer because you have to go a separate screen for results and switching between screens every time is very bad idea.
Use the apply button. If the Apply button is there, the user is sure that he has to tap on that to get updated results. After selecting the multiple criteria, he has to tap apply to make them work.
If you make the search possible on back button too (which won't harm if no criteria is selected), the user can get confused after selection like "heyy, last time it worked clicking on back, without selection, it should try with selections too".
So I think, it should be the Apply button that you should use.
Use case:
Enable the Google TalkBack accessibility service and navigate to an
app (e.g. Google Messenger)
In this app, assuming that you'll be presented with a list of items
to select, arbitrarily navigate to one of them using Talkback gestures (swipe right or just click once on one of them)
Rotate the screen
Expected behaviour:
The previously highlighted item should still be highlighted; the user
should be able to continue it's navigation
The Google Messenger app is a perfect example of this correct
behaviour
Messenger After rotation
My Sunshine app behaviour:
The previously highlighted item is not highlighted after Screen
Rotation
The user has to navigate again to the previously selected item
Depending on the screen, finding and having an item selected again can be a pain... not what we want to induce to our user
Sunshine After rotation
How should we implement this?
I'm thinking, as a solution, at Accessibility Events and intercepting them... but this doesn't seem to be right, doesn't seem to be "best practice" (e.g. creating a Custom View and implement the methods handling these Events)
! Note that the green highlighted list item doesn't seem to be focused (getCurrentFocused() returns null)
! Note that the list items become focused if we use D-Pad navigation, instead of TalkBack navigation (but this is another discussion...)
L.E:
I've spend a whole day on this, trying to "get the focus" of the
highlighted item, but the item is NOT focused. This is why I assume
that this feature must be tackled in some other way and I would like
to know your (!) experienced opinion before I spend another 2 days
re-creating all the used Android components (as I assume it could be done - this doesn't sound very "best practice", doesn't it ?)
This is NOT a homework, there's nothing wrong with my current code
(so, there's no code to post, unless one would like my whole project)
and, given that this is my first post, I could not attach more than 2
pictures (this is why the "before" screens are missing)
Just give me a good hint, based on experience, and I will implement it and post the finished, working code here.
It should work out of the box if you implement stable IDs in your RecyclerView.Adapter (and potentially disable the ItemAnimator on the RecyclerView (rv.setItemAnimator(null)) which you can do conditionally if TalkBack is enabled).
Here's a blog post I wrote about the item animator bug.
I ran into the same problem while working on the same project.
Hint: listView.setItemChecked(int position, boolean value);
Good luck :)
Please don't delete it because its a duplicate. I am an android developer with little experience. I have an app with 2 screens. The first has a bunch of options in a TableLayout each selected using a RadioButton.
What I want to do is, when I select one option and click a Button which appears below, the View should switch to the next screen showing some related data and when a Button is clicked I want it to come back to the same screen but then the rest of the options should be available to me so as to repeat the same process with another one of the options selected.
In short I want to be able to maintain the state of the first screen. I can't seem to be able to decide between using ViewSwitcher, ViewFlipper, or multiple Activities or using a single Activity which is what I am doing right now. But as my app gets bigger its very difficult to handle it. Please suggest the best way to do this. I am confused and desperately in need of help because my job depends on it. Thanks in advance
Use 2 activities. Launch the 2nd activity when the user clicks the button. When the user clicks the "back" button (or some other button you offer him) the 2nd activity finishes and the first activity (which was underneath it) is shown.
Note: You've not given us much information, so I can't guarantee that this is the best solution. From what you've said this is the solution I would recommend though. As they say in advertising "Your mileage may vary" ;-)