It probably will be an opinion based answers rather than fixed ones, but I thoughts it wouldn't be bad to ask this question and get opinions from more experienced developers.
I am implementing in my app recycler view, that each item in the recycler view should have some actions, for example
delete, reminders, spinners, change icons and some others.
Currently I implemented the delete and change icon logic with both swipe action, and contextual action mode(on click the app bar changed to "new" app bar with delete button)
I thought to continue to implement all the other actions, like reminders and spinners in the item itself but I don't know if it's a good idea.
After some research I have several approaches in my mind:
throw all the actions right in the item view itself, which mean the user see right away all the possible actions.
use popup menu(three dots on the item, and open little menu with actions)
expand the contextual action mode that will include all actions
Maybe even completely different approach and put all the actions inside the item detail screen
What do you think is a better approach?
For what it's worth, the Material Design specs (scroll down to List Controls, I can't get a link to it HOW IRONIC) recommend a primary and (optional) secondary action, with possible left and right swipe gestures (which are usually understood to be "get rid of this item" in some way, like archive and delete)
Personally I think that's a good way to go (and you don't need to follow MD but it's a good base set of principles, especially if you're not a designer or UX person yourself) - it avoids clutter, and makes it clearer to users what their main options are.
You can implement tap behaviour on the list item to bring up a dialog (fullscreen or otherwise) where you have room to add lots of other options, labels to explain them, etc. You're not limited to the size of a list item, and you can easily add to it in future if you need to, instead of being committed to trying to fit everything into a list item.
Plus there's accessibility to think about - list items are small, you don't get much space (especially on smaller devices, where the user has large fonts enabled) so where are you gonna put all that stuff? Moving some to a contextual action mode works, but there's not much space there either, and the user has to realise they need to look up there. Will it work well for blind users relying on linear navigation?
Basically you can avoid a lot of these troubles by following established patterns, where other people have done the work to make it all "just work". My own personal experience has been trying to do things in a different way, and eventually coming back to the "recommended" way and wishing I'd done that to begin with!
Related
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 :)
I have done live user testing for a list in my app, and have come to an interesting puzzle.
A list, specifically a single-column table in iOS, may often have a swipe right gesture for more actions, like the twitter app and mail app, and a million other apps. But when important functionality is embedded in the UI beyond that action, and a user cannot figure it out, the only thing that comes to mind to alleviate that is something like the accessory button, ie. a right-pointing triangle or chevron button.
There is probably another way but it's not coming to me. Maybe making the rows taller than normal?
This was meant as a comment but was rejected as too-long.
So after thinking more about this, the ideal solution is a visual clue, rather than painfully obvious text saying "swipe a row for more options". Perhaps when a list (UITableView, etc) is shown and rows (UITableViewCell, etc) are created and added, then as they appear an animation begins of the main visible content sliding into place in the OPPOSITE direction of the desired swipe animation, with a minimal visual indicator afterward, reminding the user that the content is moveable!
Sound good? Optionally, immediately before the animation begins, any underlying content may be shown for a split second (if its supposed to appear underneath). Sweet!
What is the best way to go about designing an Android application that features quite a bit of formulas and conversions? I was thinking that multiple Activities with ListViews sort of like a tree with the leaves being the actual calculations. However, after reading Android design principles it's better to avoid a pure navigational structure and try to reduce the deepness of the app.
For example:
Main Menu
Conversions
Weight
Distance
Distance - Speed - Time
Calculate air speed
Calculate distance traveled
Weather
METAR
TAF
So by the 3rd or 4th screen we've reached the actual individual calculator. Does this make sense? And if it does, is there a better way of designing this (maybe using action bars or tabs)?
By using a very simple UI concept of Expandable Listviews, in which there is more than one child row for each section of the parent row, by tapping on the "Conversions", could expand into sub-rows, likewise for each section as you see fit, and treat that as a Main Menu in a sense of a word, that is, your main application screen.
The nice advantage is that the nesting of the menus in the Android way, is eliminated and can accomodate as many as you wish.
The third or forth screen sounds like it's too deep down the rabbit hole, how about instead having multiple tabs for each "type"?
For example;
[Conversions][Distances][Weather]
If you add an ActionBar to it, you could have a type of filter as the GMAIL app has (where you select the account) and use it to toggle the different "modes" so to speak.
Another approach would be to have it all in one screen, just that you switch the active layout (or perhaps Fragment) via the filter I mentioned above.
Check out the GMAIL app, and you'll see what I mean in terms of the filter. :-)
I need some way to edit an item in my multi-line ListView - and it's just two text fields that need editing.
What would be the best way, design-wise, go about this? I feel that a whole new activity would waste too much screen space and look off, yet just a popup with the two fields and some confirm button might look off as well.
It's pretty subjective as to what's the best design for this, especially without knowing more about your specific use, however there are definitely a few possibilities that come to mind.
The new activity option that you noted is actually quite standard. You can see a similar paradigm used in Gmail, Google Talk, Messaging, etc. If your text fields expect to have something like a single word in each though, I can understand how that might feel like a waste of space to create a new activity. I wouldn't necessarily rule it out though; you can probably play around with styling to make it feel less empty (include labels, short descriptions, etc.). Also consider that most users nowadays have soft keyboards. That can take up a significant amount of space and make the view feel less empty.
The popup option seems less standard, but again if you styled it correctly I could see it working OK. What don't you like about this option?
Another option is to do a multi-pane layout of sorts which is far less common for a phone-sized layout but not out of the question. You could have a pane with two text boxes which is for the current item above your list view and have the contents change when you select an item in the list view. This is also a less standard UI.
You could also have an alternate view actually within the list item. In addition to your current (I'm assuming) two TextViews, you could have two EditTexts and maybe an OK and cancel button that are hidden. The visibility of all of these views would be toggled when you select the item.
There are more options too, I'm sure, but hopefully this will give you a little to think about at least.
I would use a separate activity for several reasons:
1) It's what users would expect. I can't recall any apps that use a pop up to edit contents of a listview
2) It'll be much easier to manage state in a separate activity e.g. when a user starts to enter some text and then gets interrupted by a call or email notification etc
3) If you're editing text then the keyboard wil take up most of the screen so you're activity won't look sparse.
you need to update in list view and add more items in list view???????
I have an app on iPhone with cascading design like on the picture, and I'd like to port it to Android. Is there a simple and recommended way to do this?
The section menu on the left (Section A, B,C,D) is the first that the user needs to select, then the user needs to pick a category in the middle (all, popular, pc, xbox,...), then he is presented with a list of articles for chosen category.
I could imagine doing it with three ListViews, but then the app could also listen to a swipe gesture to make the rightmost ListView "full screen", and hide the first two listviews. I could implement a swipe listener for the whole activity and set first two listviews' visibility to hidden, right?
Are my assumptions correct and would this be the right way to do this?
It could definetly work the way you explain it - if the design is good is another discussion. Personally I'm not a fan of throwing in endless amounts of data in one screen, when the space is as limited as it is on most mobile phones (I would probably do it with 3 different screens with a ListView on each)
Implementing the mentioned swipe gesture is doable and you could certainly just hide the two other ListViews with the function setVisibility( View.GONE ).
Hope it helps.
You might want to use the new fragments API, it's specifically built for this kind of thing (and it's compatible all the way down to Android 1.6). Also, as KasperMoerch says, putting all that info on a small screen can get ugly. Using fragments will make it easier for you to gradually increase the amount of information displayed as the screen size increases.
I'm not sure you can just listen for a swipe gesture over an entire activity like that. I think you have to wrap the fragments in a custom view (for example an extended LinearLayout) and do the swipe listening there. However, achieving a finger-tracking animation (i.e. where the rightmost pane follows the finger precisely as it swipes across) is a pretty daunting task (I wouldn't really know where to begin, probably in the custom view though). The best way (I think) to do it is to make a compromise and just start an animation (right-to-left slide) when you detect a swipe. However, the simplest solution is to not animate at all.
You can also take into consideration dropping the swipe gesture altogether and just providing an "expand" button.