I am wondering how to handle user input forms in my app. (real budget lite). Right now this is what I am doing, but I am not sure if this is the best practice:
I have two soft buttons on most of my activities that take user input: "save" and "cancel".
"save" captures the user input and then finishes the current activity
"cancel" abandons any user input and finishes the current activity
Hitting the back button on the device does the same thing as "save"
It still bothers me a little that the back button performs the function "save and go back". Users who are new to android phones are probably used to web browsers, where the back button means "forget about this page and go back to the previous page". If you were buying something online and you got to the final "purchase" page, you would not expect the back button to complete the purchase, would you? But it seems like that behavior is the way that the built-in applications work, so I am not inclined to do it differently.
Anyway, I have looked through the official documentation and I cannot find this behavior explicitly spelled out. Can someone point me to the right place, or at least provide some guidance as to best practice?
The choices as I see them are:
Do it the way I am doing it now.
Get rid of the "save" button and count on the users knowing that back equals save.
Get rid of both buttons and provide a cancel feature from the menu key.
The google contacts app provides the buttons "done" and "revert", by the way. I guess "revert" means cancel; is there a difference? Maybe I should have my buttons labeled "done" and "revert" instead of "save" and "cancel"? In gmail, the menu button provides the choices "save draft" and "discard". It seems to me that we would be doing the users a favor if we had some consistency here.
Thanks in advance.
But it seems like that behavior is the way that the built-in applications work, so I am not inclined to do it differently.
The only built-in application that does this, that I can think of, is the contacts app, and I find that UX to be lousy. I was just cursing at it yesterday, as it happens.
Perhaps other built-in apps do it too, but I haven't encountered it yet, at least not that I recall.
Anyway, I have looked through the official documentation and I cannot find this behavior explicitly spelled out.
There are no UX guidelines of this nature in the documentation. Unfortunately.
It seems to me that we would be doing the users a favor if we had some consistency here.
You would get no argument from me.
Personally, I think of the BACK button as behaving as a "cancel", or whatever the negative choice would be. Dialogs typically behave this way on Android, for example.
If you have existing users, and you have established communications with them (newsletter, support Google Group, etc.), I'd poll them and see what they think. In the end, it is what your users want that matters most.
In a pinch, make it configurable. Ideally, for something like this, there is One True Right Answer, and therefore configurability would be pointless. However, if your poll indicates a split vote, and in the absence of Android platform UX guidelines, a setting might be the right solution for you.
UPDATE: I wrote a blog post about this issue, as I think it is reasonably important and worth a bit more prose.
I highly recommend you following the model used by the standard Android and apps, where editing always happens in place. That is, there is no "save" button -- the changes you are making are effectively being saved as they are being done. (The implementation may of course be slightly different, but to the user this should not be visible.) Following that model, your buttons should be something along the lines of "done" and "revert". This helps with the user's mental model of what is going on, that leaving the activity would not be likely to turn into a "revert" operation.
One reason for using this data editing model is that you will run into many fewer bad edge cases. If you try to present a more traditional model where the user explicitly saves, then any path the user may take out of your activity is a potential cause of data loss, which then leads you to want to protect them from that, and thus trying to show dialogs to confirm that they really want to lose their data. This is a losing battle, and you will never be able to catch all of the holes out, and your UX will suffer for it. (Consider for example if they receive an incoming phone call, this is just not the time to put up a dialog to first ask them if they want to save their data, nor would you be able to anyway.)
So start with your basic model being edit in place. This is consistent with the convention the standard platform uses, and this was deliberately chosen in the platform design because overall it results in a much simpler and more consistent and comprehensible UX. Design your UI flow to emphasize this model, by avoiding explicit "save" actions.
For me, I always feel 'unsafe' without a save option. For example, in GTask, when you create a new task, hitting 'back' (hard button) will save the stuff and back to prev screen. There's no soft button BTW. But I always frustrated about this.
For your app, I think you need to consider two things before deciding which way did the back button perform:
How critical is your 'save' operation (like it will place orders!)
Did your user expected to cancel stuff?
Obviously, if the save is long-processed and critical, an explicit control must be taken. (and back would not save); and for the second point, I guess GTask considered jotting notes should be quick and simple, and it should feel like jotting on paper --- it's saved, once you wrote.
Referring to what you said, back in web browser is go back and forget everything. But at the same time, Google (e.g. Google Docs) is also doing auto, background save, that it's not 'forgotten' when you back.
Trying to decide a universal action for when the user presses back makes this question a lot more difficult (if not impossible).
A much simpler approach is thinking about the context, and I see two main situations: the user is interacting with a dialog and the user is interacting with a regular activity.
Interacting with a dialog
If an user presses back in a dialog (for instance date time picker dialog) it's because he doesn't want to see that dialog or change that information.
While in a dialog, the user doesn't expect changes to apply until he says so (by pressing "Ok").
Interacting with an activity
For example, the user is seeing the details of some item that your application provides (contact information). Pressing back after some changes could mean "now take me back to the list of contacts". Anyway, this is not 100% clear. So including options to save and discard changes (call it whatever you like) could be a good option.
My thoughts as an android user
The behavior in a dialog is simple and clear. I think we have no doubts about it.
In activities, I'm used to have the back key to save data and send me to the last activity. Whenever I want to discard my changes, I find myself pressing the menu button and looking for a button to cancel.
If you want to something better, include the default behaviour as a preference and/or display a toast when you cancel or save the information.
Cancel vs revert
In practice, they do the same thing. Cancel should, herr, cancel what you are doing right now (editing something). This should/could take you to what you were doing before (list activity).
Revert will change the state of what you are seeing to the way it was before you started doing changes. This may not take you to the previous activity. It could simply update the UI to the original values.
Experiments with contacts application
Pressing back while editing a contact will save the changes.
Pressing home while editing a contact will discard changes
Related
I have activity A with recipes that opens activity B for more options for a recipe.
In activity B I'm doing an action (like adding to favorites) that finishes activity B.
When doing that action, I'm triggering a Talkback announcement so that the user knows the action has been completed successfully.
However, the announcement gets interrupted halfway through because activity B is finishing and Talkback starts announcing activity A instead.
How can I make sure that Talkback announcements are not interrupted? Is there any way to change the priority in the API (similar to live regions?)
I also tried adding a Toast, but the toast announcement gets interrupted as well...
Any suggestions?
Thanks!
I have run into issues like these as well. I did not find a way to stop interruptions, but generally use the following approaches to get around the issues:
Keeping announcements short whenever possible. "Item With A Long Name has been saved to your favorites list" is too long, at that point user has a lot of context and has an expectation of what is going to happen, so short announcement is usually fine. Something like "Favorited"/"Saved" is to the point and takes way less time to be announced! This is important with translations as well, some languages are so much longer than others.
Used carefully and only very infrequently: Adding a delay. Send announcement, set a timer for 500ms or whatever it needs to be, accounting for translations lengths too, finish activity after that. This is something that ideally will not need to be used a lot: only for very important announcements which shouldn't be missed! Having delays could badly affect user experience, so for me this is the last strategy.
I have a rather peculiar case on my hands, and Im surprised that noone seems to have written about it/something similar for Android (or my Google skills suck)
Situation #1:
User can input text into field1 and field2.
User can also re-arrange items in a list (displayed in a RecyclerView)
Whenever the user does any of the edits, the UI is already showing the updated data (e.g. editing field1 will show the text as the user types it, and the list of items will show them in the new order as the user re-arranges them).
Saving the data right away here will trigger the UI to refresh (to display the same thing) and give the user a bad experience (field1 focus will shift to the first letter, and the app might crash if the user quickly re-arranges list items).
So it makes sense to store the edits and execute them at a later point.
Situation #2:
User can tap plus/minus buttons to increase/decrease a value
User can input text into field3.
As in situation #1 above, editing the field will already have the UI in the updated state. But, in this case - tapping the plus/minus button will also update the data, but the UI will not be updated (unless the data is saved, and the query ran again...).
Problem:
If data is saved immediately as the user performs an edit, besides doing a lot of saves, it makes for a bad user experience as the UI will refresh in some cases whereas its already up to date.
If the edits are tucked away and performed at a later point, the UI wont refresh.
Im using MVVM, so all performed actions are sent to the viewmodel and it decides what to do. I find myself looking for a solution that works differently across different screens of the app, but I know that would just be shooting myself in the foot and then jumping off a bridge. Surely, there must be someone out there that has come across this challenge and had some insights around it?
Ideal solution: One solution that just works for all the different screens. Do you have it? Please let me know.
/ Desperate Android Dev
First of all, let me start by stating that I don't think there is a correct answer here, but you should consider what your own app does and then determine what you need to do.
Let me explain. Consider two application, one that saves TODO items and the other is a banking application.
I will now explain what I think could work for your application, since you have not mentioned explicitly any requirements that contradicts that.
In situations like that, I believe being optimistic is a good idea. Assuming that things will not fail, and when they do, try to back out. What does that mean?
That means, for example, in the scenario you mentioned, user enters something in a field. You should let the UI update automatically (Nothing we do here, that's just Android), when that happens you save those changes either locally, or to a server, doesn't matter.
Of course, you can optimize, instead of saving each letter, throttle the input somehow, but you get the idea.
This can either be a succeed or a failure, because we are optimistic, we let the UI update and the user get the feel that our application is lighting fast. You don't need to reload anything, or refresh anything. The UI should match your Model state now already.
What if the things go south, and your HTTP request or DB update fails for some reason, then you need to take action. But try to keep your reaction appropriate.
You can handle that failure in so many ways, again, depending on how critical what you are doing in your app really is.
You can just show a Toast, or even do nothing if the user action was so trivial.
You can show the user something a bit more concrete if the action is of some significance, maybe a Snakbar with retry and explanation of what happened.
You kill your process and finish all activities -kidding don't ever do that- but showing a very intrusive pop-up and possibly reverting the UI value to the correct one, if what the user was doing is quite critical.
Now this approach doesn't just give the feel that the app is really fast, but it also keeps things simple.
Another advise is don't try to solve problems that don't exist yet, that means don't start implementing background services and job queues for some local persistence jobs that never outlive a view, and could never will.
Instead, use measurements, log those errors and failures with some tool, and use those stats to know what needs to be fixed -if any-
Back to our two applications, this approach might be perfect for a TODO app, however this might not be too good for a banking app.
Assume the user transfers money, we say immediately, ALL GOOD MATE! and then the request fails and your user's landlord kicks him out for never paying rent.
So it all comes to how sensitive the operations your're doing.
After reading through all the questions on SO regarding this topic i am extremely annoyed by this.
Crashes will happen, no one writes perfect code. And there are apps that require a certain logical hierarchy. The best example is the login-screen idea, where you are in some activity doing something on a server and now the app crashes. After a restart, the app lost all its login-session data and saving it might not be the safest idea. So presenting the user with the login screen after a crash would be the best and most logical thing to do. The best user experience.
However Android decides to remember the Activity stack but only restart the last working activity with a "blank" application under it.
The only viable option i see would be to check in EVERY single activity if some login state is available or not and if not, start the login (launcher) activity with a clear-top or clear-task. But this almost forces you to write a base extends Activity class in which this behavior is implemented and then all activities have to extend that. But what if, for some reason, you cannot extend it because you need to extend some other type of activity?
There is android:clearTaskOnLaunch but this happens every single time the user returns from exiting via home button. There is the antagonist finishOnTaskLaunch that finished an activity every time the user presses the home button. So the Android devs are aware that sometimes one would like the app to appear in a certain state after exit but a crash seems to be exclusive to all that.
Using a custom UncaughtExceptionHandler gives me some chance to act after a crash but as the apps state is unrecoverable i can only perform certain tasks that will happen in addition to Android very own behavior.
So my simple question is, if there is any way, that is built into Android, that allows me to change the after-crash-behaviour of Android in a natural way that does not depend on the version it's running (to some extent ofc) and will result in a somewhat smooth user experience.
I would say the proper way of obtaining the result you would like would be to provide a proper parent or up navigation stack. You can read about it more here https://developer.android.com/training/implementing-navigation/ancestral.html.
But the gist of it would be to use the idea of parent activities to provide proper back navigation. If the activity already exists it will just go back to it, if it doesn't (such as in the crash scenario) it will launch the correct activity when the user navigates back.
NavUtils is a handy class to help build this behavior and is part of the support library which would work on a range of different API levels.
I'm wondering why I still see a lot of apps (including fb & instagram) that use pull to refresh feature for updating content? I mean, they have notification system that can tell itself to refresh when there's new data. I see that FB for instance it has little bubble in the news feed section that tells me i have new feeds up there and it can take me to it if i press it, but the pull to refresh functionality is still there. Why?
This is a great question. I'm interpreting it from the perspective of user experience.
Fast Company did an interview with Kevin Systrom a few years ago when Instagram added pull-to-refresh. He wasn't into the idea.
Systrom feels the gesture, which enables mobile users to refresh their photo feeds with a simple tug of the thumb, is a superfluous addition to his app, a relic of another smartphone era. "I don’t believe there should be refresh buttons," he says.
You're right that applications don't need to provide manual refresh capabilities. I'd say that pull-to-refresh and other user initiated actions fall under a category of interfaces that return agency to users, rather than relying on automatic processes to accomplish a task — in this case, refreshing content.
There are a few questions a user might ask if pull-to-refresh was removed from the examples you've given.
How do I get new content?
How often does this content refresh?
Does the user know that the content is automatically kept up-to-date? Do they trust that it's being refreshed quickly and consistently?
Nielsen Norman Group wrote a post late last year about visibility of system status, particularly that progress indicators contribute to a positive user experience by reducing uncertainty. I'd extend this research to pull-to-refresh and related interfaces. Maintaining a user's ability to manually perform an action that fetches new content covers two of Nielsen's ten usability heuristics — visibility of system status and user control and freedom.
In this light, a user who engages pull-to-refresh has a particular mindset: I want the latest data, and I want it now. Necessary or not, allowing them to manually refresh may be contributing to an improved user experience.
FYI: Pull to refresh was first used by Loren Brichter in the app Tweetie 2 which was acquired by Twitter later.
I think his answer to how he had implemented Pull down to refresh
gesture would be an apt answer for you question
Tweetie 2 simply took this idea from Tweetie 1, that reloading was
simply “loading newer”, and “loading newer” put new messages at the
top of the list… and activated the action based on a finger motion
that you were already doing. Why make the user stop scrolling, lift
their finger, then tap a button? Why not have them continue the
gesture that they are already in the process of making? When I want to
see newer stuff, I scroll up. So I made scrolling itself the gesture.
The gesture is only half the battle though, you need appropriate
feedback. Once the reload is activated, the scrollable area of the
list actually changes to leave the feedback UI in-place (rather than
bouncing offscreen). Without this part, the UI is unintuitive. And
once the loading is complete, the UI makes itself disappear.
Reference
It's usually better for a user to choose when to update the the news feed "like on the Social Apps".
Since its not usually good to update the content automatically when the user is still reading it.This can bring about confusion to the user.
And the pull to refresh is a qualified feature for doing the work
Also this is to save mobile data usage especially in countries where internet is expensive
Simple point by considering google's Do and Don't
Swipe-to-Refresh can be used to One-phased loading.We can use other type
progress bars ie , circular etc for loading content for the first
time and load and display all content at once or loading items when
scrolls .
You can understand the purposes clearly by going through this
In my opinion this UI component is an equivalent of refresh button which does not occupy any space and it is user friendly because join scrollable + force refreshing + loading animation + finish event
It is up to app's team to determine should they use it or not based on their possibilities
your question is Awsome.. i have some R&D on it.
see nowadays reach apps never use pull to refresh in android. because android have service that can run in background with wack-lock.
but ios have no background service.
service always consume battery best way when app is open you can one time use service and after than stop service and use swipe to sync or refresh.
hope u get some idea about it.
i have one Link for more about it.see comments that can open you for this point.
I need to remap the Honeycomb "Back" button to a button in my app (service) but after hours of search I'm still nowhere. The functionality must be there system-wise like the back button in ButtonSaviour (see market)
Most solutions for emulating the Back button are based on calling finish(). Not sure if it will work in my case since I have to call finish() from whatever activity I find on the foreground. I do manage to get the foreground application with the code
ActivityManager am = (ActivityManager) getContext().getSystemService(getContext().ACTIVITY_SERVICE);
List<RunningTaskInfo> T = am.getRunningTasks(5);
System.out.println("top activity: "+T.get(0).topActivity);
but I'm not sure how I should send a finish() intent to that..
I also tried the solution posted here http://www.anddev.org/throwing-simulating_keystrokes_programatically-t717.html but I couldn't get around the IWindowManager (has it been removed in Honeycomb?). That solution, however, looks interesting because with that I could send KeyEvent.KEYCODE_BACK from anywhere, anytime.
Please let me know which is the best way to implement this functionality SYSTEM-WIDE, i.e. from a service rather than from a specific application of mine.
cheers
PS: The app is meant to run on my own rooted tablet rather than for distribution to others.
Why does people spam the thread with advises about designs and good practices when the question clearly states that this will not be used for the market?!
Replacing android nav bar is sometimes required in some applications, even if no more than for own pleasure (or programmer satisfaction).
try from java Runtime exec
input keyevent 4
4 means back
button savior most likely uses hidden api, I had encountered that somewere, but don't remember now. When I will find it, I will post back.
The reason you're not finding an answer to this is that this is a terribly hacky way to do things and it indicates that there is something majorly broken with the design of your app. You should not be able to "call the back button," that doesn't make any sense at all. In fact, you really shouldn't change the behavior of the back button at all, users get really upset when you do that. If you have a service, and you need to send messages to an Activity, then use a messenger. But you should certainly not (and certainly cannot) be changing the behavior of other apps from your service. (This would indicate a major security flaw in the system, and would let you hijack someone else's UI, doing potentially dangerous, or at least annoying, things.)
Will the activity be open when you want to simulate the back button? If so, you could set up a timer inside your activity that checks for an exit file every 5 seconds or so. Then, from your service, create the exit file when you want to simulate the back press. When the activity sees that the exit file was created, delete that file and call finish().
As others have suggested, though, doing things this way means that you might need to rethink the app's design. What exactly are you trying to achieve?