User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
User is suppose to use this app all day in the field while taking orders. Order could be saved offline (when network is not available) and saved on server when network is available again. If the data submission fails, should I notify the user inside the app when he is probably taking another order (or any other data), or should I notify him/her at device level (something like SMS notification)?
Any best-practice studies available for the same?
Notify the user inside the app, but try to avoid interrupting their workflow.
The Nielsen Norman Group did a study on mobile intranets that touched on this topic. They gave seven strategies that help avoid errors and improve productivity for mission-critical applications. From the article:
"Recognize that, even for the most proficient practitioners, typing on glass is no picnic. Create task flows that minimize data input whenever possible. Letting users select from a list, search a set list of options, or receive auto-suggestions can help them enter information more easily. ZON designed its mTec search with type-ahead functionality rather than offering users a long list of options. This reduces the burden for mobile users, leaving data-entry intensive work for when they're in the office."
What causes most of the errors in the first place? They also suggest to scrutinize the workflow itself. Sometimes the translation from a desktop app to mobile app can introduce issues.
"Design workflows for common tasks. Doing this forces the design team to fully analyze the steps and task order required to complete the work. Creating logical flows that lead users down a path reduces the burden on them. In our survey, several teams ran into problems when the process they were trying to recreate in a mobile site or app was broken to begin with. If an offline or desktop-based workflow isn't streamlined or logical, a mobile design based on it won't be either. In these cases, it’s best to redesign the process first, and then take it mobile."
Interruptions can make data entry more difficult and lead to more errors. Interruptions at the device level for an error in an app could also confuse the context of the workflow. Consider trying to avoid interruptions not directly related to the current workflow, and notifying them of errors unrelated to the current order at a more convenient time.
I'm just going to address the OP's problem statement in my reply below with existing and proven trends.
Your best solution is to just ring/vibrate the device and show a persistent OS notification. keep vibrating the device and/or make sounds regularly (with brief intervals say one every minute) until user sees or discards or approves your notification.
What you also need is an Error state design, read on...
Any best-practice studies available for the same?
The Best practice is available. As much as I hate to agree with Microsoft - they've been doing it right for a very long time now in Outlook. Every app has the right to have a status bar - its the place where you show application level information.
If the data submission fails, should I notify the user inside the app when he is probably taking another order (or any other data)
Since you say its a mobile / tablet, you can use the notification panel to show a persistent notification (kinda what Skype or your voice mail does) just stick it in the OS'd notification panel. You can also show an app-level (i.e. inside the app) notification the next time the user opens or sees the app. Its annoying but it works and that's what you need.
Also see what Facebook does...
should I notify him/her at device level (something like SMS notification)?
An SMS is over-kill so please avoid it, just vibrate the device and show any form of persistent notification. keep vibrating the device or make sounds regularly (with brief intervals) until user sees / discards your notification.
Give the user an in-app message that the data will be sent later. In your app you can use some kind of counter (or inbox) to show how many orders are yet to be synced. To notify of that number outside the app, you can use the app icon counter on the home screen:
You could give the user the option to turn off the in-app notification. The counters will still tell the user that there is unsynced data.
Note 1: I use iOS as an example but for Android and Windows Phone there are some other solutions for this: https://stackoverflow.com/questions/8292679/badge-on-android-tabhost http://developer.nokia.com/Community/Wiki/Working_with_Live_Tiles_in_Windows_Phone_7
Note 2: There will always be some dependency on the user's responsibility. Notifications outside the app can be turned off. There's nothing you can do about that except advising users not to do so.
Others have covered the use cases well. I have noticed one thing that is missing from the discussion: information security. Enterprise users, and enterprise IT, often have concerns about information security. If your application is using sensitive data, the enterprise might not allow for that data to go through someone else's cloud. You might not be able to use the device's notifications (or SMS) if the notification were to include sensitive data. There are instances where security limitations will require you to only use in-app notifications and not device-level notifications.
It seems that an app notification is less intrusive than a SMS.
However, a notification is useful only if you need the user to act; if he has nothing to do and the problem can be solved by itself you don't need to bother the user. A simple indicator (done/pending) would do the job.
Notifications should be configured to be sent either by in-app or SMS or any other means of messaging (email etc,). Most of the time, users will use the mobile application for all their work, so most of the notifications should be displayed in it for additional processing (tight integration with the rest of application). On the other hand, SMS might be a little distracting (for simple notifications) while at the same time difficult to integrate with the main app. For more serious cases, though, such as errors or warnings, SMS could be effective.
It is probably best to display an unobtrusive status bar at the top or bottom of the screen inside the app indicating that the application is not connected to the server. This is how your phone tells you when you have a data connection, so it is a familiar paradigm.
