In a mobile app, I have a section which contains a short form to let people contact me. They are able to write their name, email, company, and the reason they want to contact me. I happen to automatically get the email from the accounts information, so that's prefilled. I also add before field, a button so that the user can send me an email instead.

However, I've thought... what could I do when the user's not connected? In that case.

I've thought I could tell them they're without connection, and keep in memory the fields they filled, so the next time they enter the form, the info's still there and they can try it again and, in case it happens twice more, (that is, they hit [Send] three times without success), the app should pop a modal, telling that it couldn't connect some times, and give the chance to send all the prefilled information through email. That way, I'm releasing the issue of keeping a background task fetching for connection and trying to send it when I can, draining battery on the go.

However, despite I thought this process, it still seems a little old school to me. Would you present it in another way? Let me rephrase the process:

  1. On open, the user chooses to send an empty email with a prefilled Toand Subject.
  2. The user fills the fields he wants and hits [Send]
  3. On enquiry sending:
    1. If the enquiry is correctly sent, the fields are emptied, and a subtle success message is presented.
    2. If not, the data is saved for the next time the user wants to send the enquiry
      1. In case it fails 3 times for the same enquiry, it proposes the user a modal to send the enquiry through email, instead, with a prefilled Content, Subject and To.

1 Answer 1


Is this a native mobile app or a web app?

Either way, I think it's important to give users some indication about what is happening rather than leading them hanging, so if at all possible, you should help them feel their task is complete.

Whether a native app or web app, it's a fairly straightforward solution to persist the data in a native app for your purposes (in fact, modern web frameworks supporting local storage also make this more straightforward than in the past, but I'm assuming you need to cater to users with less than evergreen browsers).

I empathise with your concerns about email as a fallback feeling 'old school', but keep in mind that this means that (1) it's well-supported across users in that the vast majority of users have an email account, and (2) it just works, making it a very reliable candidate solution - the most important thing is that it works.

Using a modal to bridge the gap may not be the best solution on its own if you're concerned about usability on a mobile or in older browsers unless you have fallbacks, but otherwise your proposed plan seems reasonable to me.

  • Hi @kbwatts, thanks for sharing. Yeah, it's native, and I present the user a ProgressDialog telling him to wait a moment. Afterwards, depending on what the output was, I show a Confirm or Alert Crouton. My idea was to also present a modal explaining the poor connection situation, and two options, to keep waiting, or send the email. Anyway, despite yours is a good encouraging answer, let's wait for others to tell something. Here's a +1, though! Nov 20, 2014 at 11:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.